Transcript Object-Oriented Software Development

Object-Oriented Software
Development
Dr. Mao Zheng
Department of Computer Science
University of Wisconsin-La Crosse
Major Topics
• Introduction to object-orientation
– Procedural Vs OO
– OO life cycle
• Definitions and Concepts
– Objects and Classes
– Relationships among classes
• Association, Aggregation, Generalization
– Distinguishing Features of OO
• Encapsulation, Polymorphism
– Parameterization and abstraction
• Transforming functional requirements to OO
design
CS 546 - OOSD
2
Major Topics (Contd…)
• OOA/OOD notations
– UML
• UML in detail
– Various views and notations in each view
– Examples
• Object-Oriented Programming
– Language Features
– Comparison of OO languages
• Java, C++, Smalltalk, Eiffel, Visual Basic(?), C#
CS 546 - OOSD
3
Major Topics (Contd...)
• Advanced topics, if time permits
–
–
–
–
–
Object Constraint Language (OCL)
Object-Oriented Program Testing
Object-Oriented Software Metrics
Object-Oriented Databases
CORBA (Common Object Request Broker
Architecture)
– COM/DCOM
CS 546 - OOSD
4
Procedural Approach Vs ObjectOriented Approach
Procedural Approach
• emphasis on functions/tasks to be
performed
• global and local data
• modular decomposition and composition
• execution thread defined in terms of
sequences of procedure or function calls
CS 546 - OOSD
6
Procedural Approach - Example
A grocery store sells a collection of items.
Information about the items and prices are kept in
a database. A customer purchases a set of items; a
bill is produced for the items purchased; the bill
also includes taxes (shown separately). For
simplicity, it is assumed that the customer pays
cash only. The system must display change, if any,
after the customer pays. It also needs to update the
stock after each purchase.
CS 546 - OOSD
7
Procedural Approach – Example
(continued)
• Tasks to be implemented:
–
–
–
–
Add an item information to the database
Retrieve an item information while purchasing
Update the stock of the item being purchased
Compute the subtotal and tax, and also the total
for a purchase.
– Compute the change, if any, after a purchase.
CS 546 - OOSD
8
Object-Oriented Approach
• emphasis on objects involved
• encapsulated functions and (sometimes)
global functions
• modular decomposition and composition
• execution thread defined in terms of
messages passed among objects
– This is different from simple method calls in
procedural paradigm
CS 546 - OOSD
9
Object-Oriented Approach for the
Example
• Objects
– Item, Database, Bill, Date, Grocery Store, …
• Encapsulated Structure
– Item
• ID, description, price, quantity, …
– Database
• Collection of items
– Bill
• Date, collection of items, subtotal, tax, total, change, …
CS 546 - OOSD
10
Object-Oriented Approach –
Example (continued)
• Encapsulated functions
– Item
• Change price, change quantity, …
– Database
• Store an item, retrieve an item, update an item, …
– Bill
• Compute tax, compute total, compute change, ...
CS 546 - OOSD
11
Procedural Vs Object-Oriented
• one is the dual of the other
– both approaches capture more or less all the essential
features of the end product
– rigorous proof exists
• emphasis and software development processes
differ
– generally, end users do not see the difference
– Was “Windows XP” developed using procedural
approach or OO approach?
CS 546 - OOSD
12
Why do we use the ObjectOriented Approach?
• encapsulated structures and localized
behaviors
– separation of concerns
• easy to change/extend/maintain
• promotes reuse – better reusability than the
procedural approach
• modularization visible
CS 546 - OOSD
13
Introductory references on OO
• G. Booch, “Object-Oriented Software
Development”, IEEE Transactions on Software
Engineering, Vol. 12, No. 2, Feb 1986, pp. 211221.
• G. Booch, Object-Oriented Design with
Applications, Benjamin Cummings Publications,
1991. (Second edition: OO Analysis and Design
with Applications, published in 1994).
CS 546 - OOSD
14
Object-Oriented Software Life
Cycle
Stages in OO life cycle
• Requirements engineering
– requirements gathering, analysis and specification
– inherently procedural because customers describe what
the software system is supposed to do
• OO Design
– architectural design
– detailed design
– both require the transformation of functional
requirements into OO design elements
• Implementation or Coding or Programming using
OO programming languages and tools
CS 546 - OOSD
16
Stages in OO life cycle
(continued)
• Testing
– unit testing; test methods within each object
– integration testing; test collaborations between
objects
– system testing; test the entire system as a
collection of objects
– acceptance testing; test for standards and
customer satisfaction
CS 546 - OOSD
17
Procedural and OO paradigms
Procedural
requirements
OO
requirements
OO design
Procedural
design
Implementation
in a procedural
language
Implementation
in an OO
language
CS 546 - OOSD
18
Maintenance
• fixing bugs, enhancements, adapting to changing
environment
– all the three activities require that some objects to be
changed; easy to trace those objects
• add developed classes to library of classes, if
appropriate
– generalization
• (possibly) create patterns and frameworks
– reuse
CS 546 - OOSD
19
Spiral Life Cycle Model
• a prototyping model used for OO software
development
– develop an initial set of objects (from the
requirements document)
– evaluate these objects against feasibility, risk,
cost effectiveness, quality, etc.
– modify the objects based on the evaluation
– iterate the process until the product is finalized
CS 546 - OOSD
20
References for spiral model
• B. Boehm, “A spiral model for software
development and enhancement”, IEEE
Computer, May 1988, p. 61-72.
• Pankaj Jalote, An Integrated Approach to
Software Engineering (Second edition),
Springer-Verlag, 1997.
CS 546 - OOSD
21
Definitions and Concepts
Object
• models of real-world entities
– TV, VCR, Stereo system, …
• may also represent program entities
– array, queue, stack, linked list, …
• may also be used to model fictitious entities
– seminar, dream, …
CS 546 - OOSD
23
Object (continued)
• has structure and behavior
• structure is identified by one or more data
components
– each data component is defined as a
<name,type> pair
– examples
• A TV has a screen, connections, model, …
• A stack has a sequence of items
• A dream has a theme, duration, …
CS 546 - OOSD
24
Object (continued)
• behavior
– operation that can be exercised on the object
• switch the TV on – exercised on a TV object
• Give/start the seminar - exercised on a seminar
object
– task performed by the object
• display - performed by a TV object
• count time - performed by a seminar object
CS 546 - OOSD
25
Object (Continued)
• objects can be composed to form a composite
object
– a TV object is composed of several component objects
such as screen, connections, display unit, etc.
– several seminar objects can be composed to form a
course object
• objects can interact with each other
– a TV object can send a signal to a VCR object
– a user object interacts with a seminar object to change
the contents of the seminar
CS 546 - OOSD
26
Object (Continued)
• objects can be specialized
– a TV object can be specialized into a projection
TV object
– a seminar object can be specialized into a
colloquium object
• objects can be generalized
– TV objects, VCR objects and stereo system
objects can be generalized into electronic
system objects
CS 546 - OOSD
27
Object (Continued)
• objects are generally concrete and well
defined
– TV object, VCR object, seminar object, …
• sometimes objects can be vague (with
incomplete structure and/or behavior)
– an object that corresponds to an understandable
seminar or a seminar on a totally new topic
– an object that corresponds to the internet
CS 546 - OOSD
28
Question?
• What characterizes an “object”? In other
words, how do we identify an object from a
problem description?
– an object should possess at least a structure or a
set of behaviors, preferably both
– an object can be primitive and well-understood
• an integer
– an object can be complex and hard to
understand/define
• The internet
CS 546 - OOSD
29
Object - Exercise 1
• Identify the objects in the following
problem
– A ticket counter in an unmanned parking lot
issues tickets to the vehicles when they enter. It
displays the time and charge when the ticket is
inserted back into the machine while leaving.
The machine also accepts bills and coins and
returns change, if any.
CS 546 - OOSD
30
Object – Exercise 2
• Identify the objects in the following
problem
– The Computer Science department wants to
create a home page. This home page should
provide links to all the faculty members’ home
pages, to a list of course descriptions, to a list of
job vacancies in the department, to the
University home page and to the email address
of the secretary, if someone wishes to contact
the department.
CS 546 - OOSD
31
Class and Objects
A class represents a collection of objects who share similar
structure and behavior
• Class
– TV
– Stack
– Seminar
• Objects
– Sony TV, Hitachi TV
– Stack of integers, stack
of reals
– Kasi’s Seminar, Bill’s
seminar
CS 546 - OOSD
32
Class Vs Object
• templates
• created/defined by
programmers
• can be abstract
• one class represents a
collection of objects
• actual structures with
values (concrete)
• created by run-time
system
• cannot be abstract
• each object belongs to
exactly one class
(traditional definition)
CS 546 - OOSD
33
Class Vs Object (continued)
• class name serves as
an identity (to be
discussed later)
• static; serves as a
source of definitions;
possibly never be
destroyed
• possesses an internal
identity, generated by
the run-time system
• dynamic; created and
destroyed during
execution; some
objects may persist
even after termination
of execution
CS 546 - OOSD
34
A bit of Theory
• classes are implementations of Abstract Data
Types (ADTs)
• an Abstract Data Type (ADT) is defined only by
its behaviors without committed to any
implementation
– a TV ADT
• a behavior: must display a motion picture
• no matter what picture is displayed (color, black/white, sports,
kids program, …)
– a seminar ADT
• a behavior: must have a topic and contents
• no matter in what format
CS 546 - OOSD
35
A bit of Theory (continued)
• classes are implementations of ADTs
• Why? a class has a structure, along with its
behavior
– The integer data type is an ADT
– The integer class in OO has a representation and hence
a limitation (32 bits, 64 bits etc.)
– The stack is an ADT
– The stack class has a structure; may use an array for
implementation; has a limited size
CS 546 - OOSD
36
A bit of Theory (Contd...)
• interested more??? read “Object Calculus”
by Abadi and Cardelli, 1996, SpringerVerlag.
• we discuss a bit of type theory in OO later
in this course (of course, only if you are
interested!!)
CS 546 - OOSD
37
Encapsulation
• James Rumbaugh et al., 1991
– a mechanism by which external aspects of a class that
are visible to or accessible by other objects are
separated from the internal or implementation details of
these aspects
• Grady Booch, 1994
– a process of compartmentalizing the elements of an
abstraction that constitute its structure and behavior
– serves to separate the contractual interface of an
abstraction and its implementation
CS 546 - OOSD
38
Encapsulation- Examples
• Class TV
– external interface:
• structural: size, type, model, price, connections,…
• behavioral: display, picture-in-picture, send_signal,
…
– internal details:
• structural: power, heat-dissipation, dimmer, …
• behavioral: switch_mode, color_adjust, …
CS 546 - OOSD
39
Encapsulation- Examples
• Class Seminar
– external interface:
• structural: theme, contents, duration, …
• behavioral: start, end, deliver, …
– internal details:
• structural: sequence of sentences, heading, …
• behavioral: change topic, change contents, sort, …
CS 546 - OOSD
40
Encapsulation - Exercises
• Give the external interface and internal
details of each one of the following classes:
– Ticket counter in the Parking lot
– Database
– Player or parent, in your project
CS 546 - OOSD
41
Encapsulation – a question
• How to identify/characterize external interface and
internal details?
– needs application domain information and access
restrictions
• what seems to be an external interface for one
person may be an internal detail for another person
– levels of access restrictions
• public, private, protected – terms used by C++ and
Java
• not just these; may be more
CS 546 - OOSD
42
Encapsulation Vs Information
Hiding
• Encapsulation is a concept
• Information hiding (how to) is a
concretization process of encapsulation
(what)
– information hiding implements encapsulation
• OO analysis deals with encapsulation
• OO design and implementation take care of
information hiding
CS 546 - OOSD
43
Communication between Objects
• objects communicate with each other or interact
among themselves by message-passing
• single thread of control - client-server mode of
communication
– client sends a message to the server indicating the
request and the server sends the response back to the
client through another message
– requires that the client and server know each other
– communication link established statically or
dynamically
CS 546 - OOSD
44
Communication (continued)
• multiple threads of control
– each object sends messages to one or more
objects and continues to execute its own tasks
– information shared through messages
– each object should know the other objects with
which it communicates
– communication link established statically or
dynamically
CS 546 - OOSD
45
Communication (continued)
• pre-defined / static communication links
– designer / programmer knows / decides well in
advance the links between the objects
– explicit in the class definitions
• inheritance, aggregation, association (will be
discussed shortly)
• dynamic communication links
– decided at run-time
• delegation (will be discussed later)
CS 546 - OOSD
46
Communication – Example 1
• objects: a student and a course
• communication link: static (association)
• scenario 1:
– the student object sends a request to the course
object to check for availability of seats in that
course
– because the link is static, this communication
must be explicit in the design / code
CS 546 - OOSD
47
Communication – Example 1
(continued)
• scenario 2:
– the course object sends a request to the student
object to update its information on the list of
courses registered (after a successful
registration process)
– because the communication link is static, the
information about this link must be available in
the design / code
CS 546 - OOSD
48
Communication – Example 2
• objects: two speaker objects
• communication link: dynamic
• scenario 1:
– one speaker object raises a question and the other
speaker object answers to that question
– because the communication link is dynamic, the first
speaker object does not (need to) know who the other
speaker object is
• example: teacher and student
• example: a speaker in a seminar and a person from
the audience
CS 546 - OOSD
49
Communication - Exercises
• Define a communication scenario between a
driver object and a car object.
• Define a communication between a file
object and an editor object.
• Define a communication between a stock
object and an investor object.
CS 546 - OOSD
50
Static Relationships among
Classes
Static Relationships
• decided during the analysis phase and/or the
design phase, and carried over to the
implementation phase
• establish static communication links
• three types
– association
– aggregation
– specialization / generalization
CS 546 - OOSD
52
Association
• represents one or more conceptual connections
between objects
– included in the definitions of the respective classes
• denotes a semantic dependency between the
objects
– what is a “semantic dependency”?
• some relationship that is meaningful in the chosen
application domain
• how do we determine whether or not it is
meaningful?
• depends on the application domain and the
designer’s understanding of the application domain
• synonymous to “relation” in databases
CS 546 - OOSD
53
Association – example 1
• In a course registration system,
– a student object has an association with a
course object
• the student object depends on some
information on the course object
– the course object has another (different)
association with the student object
• the course object needs to know the
identification of the student if he/she
registered for that course
– both associations are unidirectional
CS 546 - OOSD
54
Association – example 2
• In a home theatre system,
– a TV object has an association with a VCR
object
• it may receive a signal from the VCR
– the VCR object may have another (different)
association from the TV object
• it may receive a signal to record
– both associations are unidirectional
CS 546 - OOSD
55
Association (continued)
• N-ary associations (n >= 1)
• unary association
– from a class to itself
– “Person” to “Person” (boss and worker)
– “Student” to “Student” (graduate student teaching
undergraduate student)
• Binary
–
–
–
–
between two different classes
“Student” and “Course”
“TV” and “VCR”
“Parent” and “Player”
CS 546 - OOSD
56
Association (continued)
• ternary
– Between three different classes
• Each pair has a relationship and there is a common
relation that involves all the three classes
– “Doctor”, “Patient” and “Appointment”
– “Team”, “Player”, and “Tournament”
– “Lecture”, “Teacher” and “Time”
CS 546 - OOSD
57
Association (continued)
• generally identified during the analysis phase
– not all associations are refined into the design phase
and/or into the implementation phase
• some are useful in understanding the application
domain and may lead to a better design
• n-ary associations may give clues to identify
concurrency issues
• associations are always named in OO modeling
CS 546 - OOSD
58
Association - exercises
• Give some objects and their associations in the
parking lot ticketing system that was discussed
earlier
– Give at least one pair of objects that are associated and
another pair of objects that are not associated
• Give some objects and their associations in a form
filling system in a hospital environment
– Give at least one pair of objects that are associated and
another pair of objects that are not associated
CS 546 - OOSD
59
Specialization
• specialization is also called “is-a” relationship
• specialization describes how one class becomes a
specialized version of another class
– there must be some difference between the two
classes but there must also be some
commonality.
– the commonality and differences must be
justified from the application domain
– do not use specialization relationship just for
code reuse purposes
• some early AI languages such as Lisp and Prolog
used specialization as a code reuse mechanism
CS 546 - OOSD
60
Specialization (continued)
• specialization relationship forms a hierarchy and is
defined from a child to a parent
• it is a transitive relation
– If a grandchild is a specialization of a child and the
child is a specialization of a parent, then the grandchild
is a specialization of the parent
• example:
– A Plasma TV is a specialization of a TV
– Difference: Plasma TV has more features (flat panal,
different components, …)
– Commonality: display, connections, power, …
CS 546 - OOSD
61
Generalization
• generalization is the other-side view of
specialization
• generalization describes how one class
possesses structure and behavior common to
several descendant classes
• generalization is defined from parent to
child
CS 546 - OOSD
62
Generalization/Specialization
(continued)
• the generalized class is called “superclass”,
“base class”, or “parent”
• the descendants are called “subclasses”,
“specialized classes”, “derived classes” or
“children”
• even though we are talking about classes,
the relationship is equally applicable to the
objects instantiated from these classes
CS 546 - OOSD
63
Multiple generalization /
specialization relationship
• a subclass may be a specialized version of more
than one superclass
• it is called “multiple inheritance property” in OO
programming languages
• designers must ensure that the properties inherited
from the multiple superclasses do not clash with
each other
– most of the OO programming languages provide some
mechanism to work around this problem
CS 546 - OOSD
64
Generalization/specialization exercises
• Give some classes in a library catalogue
system and show the
generalization/specialization relationships
among them
• Give some classes for vehicles in a car
dealer shop and show the
generalization/specialization relationships
among them
CS 546 - OOSD
65
Aggregation
• also known as “has-a” relationship, and “part-of”
relationship
• synonymous to “record” in Pascal, “structure” in
C
– basic idea is to group a set of entities/fields into one
single bundle and use it as a single entity
• denotes composition of objects
– an aggregate object encloses a component object
– The aggregate object cannot exist without the
component but a component may exist without the
aggregate
CS 546 - OOSD
66
Aggregation (continued)
• examples
– a TV object encloses a screen object, several
connection objects, …
– a home theatre system object encloses a TV
object, a DVD player object, a TV object, …
– a seminar object encloses a contents object, a
theme object and a duration object
CS 546 - OOSD
67
Aggregation (continued)
• sometimes reflexive (recursive aggregation)
– a procedure may contain another procedure (Pascal)
– a class may contain another class (Java)
– requires careful design and implementation
mechanisms
• aggregation is also an association
– Is it not interesting to know?
• a TV object contains at least one connection object
• so, the TV object depends on the connection object
 existence of a semantic dependency
CS 546 - OOSD
68
Aggregation - exercises
• Give some classes in a cruise control system
and show the aggregation relationship
among them
• Give some classes for a library catalog
system and show the aggregation
relationship among them
• Give some classes in a form-filling system
in a hospital and show the aggregation
relationship among them
CS 546 - OOSD
69
Confusion between
Generalization and Aggregation
• often, designers and programmers
(particularly the latter) get confused
between generalization and aggregation
– consequence: choose the wrong relationship
– will this decision affect the software product?
• YES… in the long run.. may not be significant
CS 546 - OOSD
70
Generalization Vs Aggregation
• relationship between
objects, even though
their respective classes
are used to define the
relationship
• objects of these classes • objects are related by
composition
are totally unrelated
• sometimes reflexive
• not reflexive
(recursive
aggregation)
• relationship between
classes
CS 546 - OOSD
71
Generalization Vs Aggregation An Example
• Toyota Corolla is a Car
– by “is a” relationship, we can say Corolla is a
specialization of a car
• the class car has an attribute called “model” which
is instantiated with the value “Corolla”
– car is an aggregate and “Corolla” is the value of one of
its component, namely model
• both are correct indeed
– which one to choose…. depends on the context
CS 546 - OOSD
72
Generalization Vs Aggregation –
Another example
• an ENT specialist is a specialization of a physician
in a hospital
– specialization relationship
• a physician object includes a field called
“specialty” that describes the specialization of a
physician
– aggregation relationship
• the first one may be used in the hospital whereas
the second one may be used in the City Office for
book-keeping
CS 546 - OOSD
73
Parameterized Classes
• class definitions with generic parameters
• examples:
– Sony[T] may be a parameterized class that can be
instantiated by any Sony product
– CS-Course[T] may be a parameterized class which can
be instantiated by any CS course number
• rarely defined in application classes
• structure and behavior definitions should not
depend on “T”, the parameter
CS 546 - OOSD
74
Abstract Class
• a class that cannot be instantiated
– no direct objects for this class
• at least one of its behavior definitions must be
incomplete
– example: independent student may have a
behavior “complete requirements” which is
deliberately left unspecified
• requirements for an independent student are
not known; they vary with each individual
and hence cannot be specified beforehand
• a subclass of an abstract class may itself be still
abstract
CS 546 - OOSD
75
Uses of abstract class
• intended to define the general characteristics of an
object in an abstract class with some behaviors
deliberately left undefined  make the class
abstract
• another class (may be more than one) specializes
the abstract class and complete the undefined
behavior
• basic idea is to capture more general properties
separately in an abstract class
CS 546 - OOSD
76
Abstract Class - examples
• one-level refinement
– Printer is an abstract class which includes a behavior
called “draw” but does not define the behavior
• deliberately left undefined because we do not know
the type of the printer
– Postscript printer is a concrete class which specializes
Printer and completes the behavior “draw”
– Inkjet printer is another concrete class which
specializes Printer and completes the behavior “draw”
in a different way
– Postscript printer 600 may be another concrete class
which specializes Postscript printer, but both are
concrete classes
CS 546 - OOSD
77
Abstract class - examples
• two-level refinement
– Polygon is an abstract class which includes two
incomplete behaviors “area” and “number of sides”
– 4-sided figure is an abstract class which specializes
Polygon and completes the definition of the behavior
“number of sides”, but the behavior “area” is still left
incomplete and so this class is still abstract
– Rectangle is a concrete class which specializes 4-sided
figure and completes the definition of the behavior
“area”
– Square is another concrete class which specializes
Rectangle but redefines the behavior “area”
CS 546 - OOSD
78
Metaclass
• class whose instantiations are class
definitions
• high level concept; not used by end users
• supported by Smalltalk, CLOS
• useful for tailoring an OO implementation
for a particular application
CS 546 - OOSD
79
Metaclass (continued)
• some meta-operations
– get the number of instances of a class
– assign a global variable common to all
instances of a class
– get the number of subclasses of a superclass
CS 546 - OOSD
80
Inheritance
• a mechanism to implement (normally) a
specialization relationship
– generalization/specialization is a concept, whereas
inheritance is a mechanism
– analogous to encapsulation and information hiding
• a distinguishing feature of object-oriented
design/programming
• subclass inherits features (structure and behavior)
of superclass
– interface or internal or both??
• traditionally viewed as a code reuse mechanism in
AI and non-OO applications
CS 546 - OOSD
81
Inheritance- examples
• HDTV inherits features of TV
– mechanism: adds more features
• High Definition Signal receiver is included
• Student president inherits Student
– mechanism: adds more features
• adds additional responsibilities
• Square inherits Rectangle
– mechanism : redefines perimeter and area
• restricts the length and breadth to be the same
CS 546 - OOSD
82
Three types of Inheritance
• inheritance by expansion
– subclass adds more features in addition to the
features that are inherited from the superclass
• Internship student inherits Student and adds
employment details -- structural expansion
• Student chairman inherits Student and adds
administrative duties -- behavioral expansion
CS 546 - OOSD
83
Three types of Inheritance
(continued)
• inheritance by restriction
– subclass restricts some of the features that are
inherited from the superclass
– subclass does not want its objects to use these
restricted features
• Student attends Seminar, but Part-Time Student does
not need to attend Seminar
• Most credit cards can be used as debit cards as well
but some are restricted and cannot be used as debit
cards
CS 546 - OOSD
84
Three types of Inheritance
(continued)
• inheritance by redefinition
– subclass may redefine one or more features that
are inherited from the superclass
• CS department inherits Department and may
redefine the behavior “admission requirements”
• Square inherits Polygon and redefines the behavior
“area”
– structural redefinition is generally not permitted
in many OOD methods and OOP languages
since the redefinition may not be meaningful
CS 546 - OOSD
85
Inheritance - exercises
• Give some classes for a library catalogue
system and show the inheritance
relationships among these objects; indicate
which type of inheritance is used
• Give some classes for the vehicles in a car
dealer shop and show the inheritance
relationships among these objects; indicate
which type of inheritance is used
CS 546 - OOSD
86
Polymorphism
• generally implementation-oriented, but still
can be considered at the design level
• “ability to exist in more than one form”
- Oxford Dictionary
• advantage in OO design/programming
– able to use one class/object/method in multiple
contexts
CS 546 - OOSD
87
Types of Polymorphism
• universal polymorphism
– parametric polymorphism
• provided by parametric classes
• when parametric classes are instantiated, they exist
in different forms
– Examples
• CS-Course[546], CS-Course[341]
• Sony[TV] and Sony[DVD]
CS 546 - OOSD
88
Polymorphism (continued)
• universal polymorphism (continued)
– inclusion polymorphism
• supported by inheritance
• subclass objects substituted for superclass
objects
• a subclass object when substituted for a
superclass object behaves identically as a
superclass object
CS 546 - OOSD
89
Polymorphism (continued)
• Inclusion polymorphism examples
– a Flat panel TV can be substituted for a TV
– a student seminar can be substituted for a
seminar
– a Student President object can be substituted for
an object of Student
– a CS faculty member object can be substituted
for a University faculty member object
CS 546 - OOSD
90
Polymorphism (continued)
– inclusion polymorphism (continued)
• valid only for inheritance by expansion
• if inheritance by restriction or inheritance by
redefinition is used, the subclass object WILL NOT
BEHAVE identically as expected for the superclass
object
• one exception for the condition on inheritance is the
use of abstract classes
• abstract classes cannot be instantiated; only subclass
objects can support when abstract class needs to be
instantiated; redefinition is mandatory in this
context, but still exhibits inclusion polymorphism
CS 546 - OOSD
91
Polymorphism (continued)
• ad hoc polymorphism
– exists at the level of behavior definitions
• more than one definition for the same behavior
• “sort” can be used to sort elements of different types
• more than one constructors in Java and C++
– mostly a feature of OO programming
– redefine operator definition (also called
operator overloading); requires language
support
CS 546 - OOSD
92