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