object-oriented software development dr. mao zheng department of computer science university of...
TRANSCRIPT
Object-Oriented Software Object-Oriented Software DevelopmentDevelopment
Dr. Mao Zheng
Department of Computer Science
University of Wisconsin-La Crosse
CS 546 - OOSD 2
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 3
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 4
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
Procedural Approach Vs Object-Oriented Approach
CS 546 - OOSD 6
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 7
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 8
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 9
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 10
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 11
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 12
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 13
Why do we use the Object-Oriented 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 14
Introductory references on OO
• G. Booch, “Object-Oriented Software Development”, IEEE Transactions on Software Engineering, Vol. 12, No. 2, Feb 1986, pp. 211-221.
• G. Booch, Object-Oriented Design with Applications, Benjamin Cummings Publications, 1991. (Second edition: OO Analysis and Design with Applications, published in 1994).
Object-Oriented Software Life Cycle
CS 546 - OOSD 16
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 17
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 18
Procedural and OO paradigms
Procedural requirements
OO requirements
Procedural design
OO design
Implementation in a procedural language
Implementation in an OO language
CS 546 - OOSD 19
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 20
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 21
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.
Definitions and Concepts
CS 546 - OOSD 23
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 24
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 25
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 26
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 27
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 28
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 29
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 30
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 31
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 32
Class and Objects
• Class– TV
– Stack
– Seminar
• Objects– Sony TV, Hitachi TV
– Stack of integers, stack of reals
– Kasi’s Seminar, Bill’s seminar
A class represents a collection of objects who share similar structure and behavior
CS 546 - OOSD 33
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 34
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 35
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 36
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 37
A bit of Theory (Contd...)
• interested more??? read “Object Calculus” by Abadi and Cardelli, 1996, Springer-Verlag.
• we discuss a bit of type theory in OO later in this course (of course, only if you are interested!!)
CS 546 - OOSD 38
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 39
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 40
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 41
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 42
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 43
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 44
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 45
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 46
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 47
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 48
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 49
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 50
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.
Static Relationships among Classes
CS 546 - OOSD 52
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 53
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 54
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 55
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 56
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 57
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 58
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 59
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 60
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 61
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 62
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 63
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 64
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 65
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 66
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 67
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 68
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 69
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 70
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 71
Generalization Vs Aggregation• relationship between
classes
• objects of these classes are totally unrelated
• not reflexive
• relationship between objects, even though their respective classes are used to define the relationship
• objects are related by composition
• sometimes reflexive (recursive aggregation)
CS 546 - OOSD 72
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 73
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 74
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 75
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 76
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 77
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 78
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 79
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 80
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 81
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 82
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 83
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 84
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 85
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 86
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 87
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 88
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 89
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 90
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 91
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 92
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