A Critical Look at Inheritance

“You can choose your associates, “You can choose your associates, but you’re stuck with your

ancestors.”

Inheritance in OOD

• Inheritance is often held to be sacrosanct in OOD.

• Tendency for OO developers to gauge the success of their efforts by the complexity of their inheritance hierarchy.their inheritance hierarchy.

• It is interesting to note that inheritance hierarchy examples in OO texts seldom deal with software design problems.

Inheritance--The Reality• Inheritance is a complex issue.

– Many different types of inheritance relationships.

– Basic notions differ among OO languages

– Some controversial issues--e.g. multiple inheritance.

– Inheritance can break encapsulation.– Inheritance can break encapsulation.

– Poorly conceived inheritance relationships can frustrate system reliability, maintainability, and evolvability.

• Inheritance is neither inherently good or bad. It must be used in a disciplined manner.

Inheritance--A Simple Classification

• Subclassing– inheritance of implementation fragments/code

from a superclass.

• Interface Inheritance• Interface Inheritance– inheritance of contract fragments/interfaces.

The Complexities of Subclassing

• Methods of a class may freely invoke each other.

• Subclasses may override inherited methods.

• Subclass methods may call methods of • Subclass methods may call methods of superclasses, including overridden superclass methods.

• This is actually a form of “callback” from subclass to superclass.

Inheritance Issues Example

Text-text: Array of Char-used:Integer = 0-caret:Integer = 0

+max( ):Integer+length( ):Integer+write(pos:Integer, ch:Char)

+setCaret(pos:Integer)

-cacheX: Integer = 0-cacheY: Integer = 0

SimpleText

+write(pos:Integer, ch:Char)+delete(pos:Integer)+caretPos( ):Integer+setCaret(pos:Integer)posToXCoord(pos:Integer):IntegerposToYCoord(pos:Integer):IntegerposFromCoord(x:Integer,

y:Integer):Integer+type(Char)+rubout( )

+setCaret(pos:Integer)+posToXCoord(pos:Integer):Integer+posToYCoord(pos:Integer):Integer+posFromCoord(x:Integer,

y:Integer):Integer+hideCaret( )+showCaret( )

Example--Continuedabstract class Text {

.

.

.private int caret = 0;

.

.

class SimpleText extends Text {...

void setCaret(int pos) {int old = caretPos( );if (old != pos) {.

.void setCaret(int pos) {caret = pos;}

.

.

.}

if (old != pos) {hideCaret( );super.setCaret(pos);showCaret( );

}...

}

Example--ContinuedInteraction diagram resulting from call to method type of Text class:

Text SimpleText Display

typecaretPos

writesetCaretsetCaret

hideCaret

(update display)Super.setCaret

showCaret

setCaret

Example--ContinuedA new version of Text class that “breaks” the subclass SimpleText:

abstract class Text {...

void write (int pos, char ch) {int i;int i;for ( i = used; i > pos; i--)

text[i] = text[i-1];used = used + 1;if (caret >= pos)

caret = caret +1;text[pos] = ch;

}...

Inheritance Issues--The Fragile Base Class Problem

• There is an implicit interface between a class and its ancestor classes (superclasses).– Syntactic aspect--Does a class need to be

recompiled due to purely syntactic changes recompiled due to purely syntactic changes among it superclasses?

– Semantic Aspect--How dependent is a subclass upon changes in the implementation of its superclasses?

Dealing With Class-Subclass Dependencies

• Specialization Interface– Interface between a class and its subclasses

– For Java and C++, the specialization interface consists of the public and protected interface of the superclass.

• Various methods have been proposed to control behavior across a specialization interface, but these are largely of theoretical interest.

Alternatives to Inheritance--Object Composition

• Object composition--composition of behavior based upon references among objects rather than inheritance relations.

• Based upon “part of” relationship among • Based upon “part of” relationship among objects.– Suppose object A requests help from object B

– B is “part of” A if references to B do not leave A.

Object Composition

B

innerouter(owning)

CA(owned)objects

(owning)object

Note: A reuses the implementation of objects B and C

Composition Versus Inheritance

• An instantiated object has one notion of self even though it may inherit parts of its implementation from several superclasses.

• “Self-recursive” invocations of methods always return to the overriding version in always return to the overriding version in the lowest level subclass

• Composed objects do not have a common self—i.e.outer object does not share identity with inner objects.

Example of self-recursive calls

BaseA( )

Sub

Base SubSubSub

A( )

uses A( )

B( )

super.A( )super.A( )usesSub

A( )

SubSubA( )

super.A( )usessuper.A( )

usessuper.A

Example of Composition

BaseA”( )B( )

uses

:Base:SubSub :Sub

AA’

A’’

SubA’( )

SubSubA( )

uses

uses

Composition--Additional Observations• Composition requires that object

interactions, including recursive interactions among objects, be explicitly designed-in rather than an implicit by-product of implementation inheritance.implementation inheritance.

• Composition is a relationship between instantiated objects, not a relationship between classes.

• Composition can be made as general as subclassing by use of delegation.

Inheritance versus CompositionAn example of multiple inheritance from

a well-known OO textAPPLE PIE

APPLE PIE

Does this make sense?

Apple Pie Example-Continued

A more sensible approach

APPLE PIE

APPLE

1

*PIE SHELL

1

1

Apple Pie example--A Compositional Perspective

Apple Pie

Pie ShellApple

Inheritance Versus Composition--Another Example

• Inheritance is generally not appropriate for “is a role played by” relationships.

• For instance, consider roles in an airline reservation system:reservation system:– passenger

– ticket agent

– flight crew

– etc.

Roles Example--A Potential Inheritance Hierarchy

Person

CrewMember TicketAgent Passenger

Is there a problem with this approach?

Roles Example--A Potential Inheritance Hierarchy

Person

CrewMember TicketAgent Passenger

Problem with this approach: a person may play different roles. An instantiated subclass can only represent one role.

Roles Example--An Attempt to Fix the Inheritance Hierarchy

Person

CrewMember Passenger TicketAgentCrewMember Passenger TicketAgent

CrewMemberAndTicketAgent

CrewMemberAndPassenger

TicketAgentAndPassenger

CrewMemberAndTicketAgentAndPassenger

Roles Example--A More Rational Solution using Composition

CrewMember TicketAgent Passenger

Uses Uses Uses0..1 0..1 0..1

Person

Uses Uses Uses

1 1

1

Note: Many authors refer to this as delegation.

TicketAgentObject

PassengerObject

Object Encapsulation via Composition

PersonObject

PersonObject

An Alternative Composition for the Roles Example

CrewMember TicketAgent Passenger

Uses Uses Uses0..1 0..1 0..1

Person

Uses Uses Uses

1 1

1

Object Encapsulation for Alternative Composition

PersonPerson

PassengerTicketAgent Flight

CrewTicketAgent

Inheritance Versus Composition--Some Guidelines

• It is generally not a good idea to use inheritance for the following purposes:– To represent dynamically changing alternative roles of

a superclass

– To hide methods or attributes inherited from a – To hide methods or attributes inherited from a superclass (restriction)

– To implement a domain-specific class as a subclass of a utility class (specialization)

– Purely for purposes of obtaining functionality needed to implement the subclass (implementation inheritane)/

Potential Drawbacks of Composition (Delegation)

• There may be some minor performance penalty for invoking an operation across object boundaries as opposed to using an inherited method.inherited method.

• Composition can’t be used with partially abstract (uninstantiable) classes

• Composition does not, in and of itself, impose any disciplined structure on the design (but neither does a class hierarchy).

A Critical Look at Inheritance

“You can choose your associates, “You can choose your associates, but you’re stuck with your

ancestors.”

Inheritance in OOD

• Inheritance is often held to be sacrosanct in OOD.

• Tendency for OO developers to gauge the success of their efforts by the complexity of their inheritance hierarchy.their inheritance hierarchy.

• It is interesting to note that inheritance hierarchy examples in OO texts seldom deal with software design problems.

Inheritance--The Reality• Inheritance is a complex issue.

– Many different types of inheritance relationships.

– Basic notions differ among OO languages

– Some controversial issues--e.g. multiple inheritance.

– Inheritance can break encapsulation.– Inheritance can break encapsulation.

– Poorly conceived inheritance relationships can frustrate system reliability, maintainability, and evolvability.

• Inheritance is neither inherently good or bad. It must be used in a disciplined manner.

Inheritance--A Simple Classification

• Subclassing– inheritance of implementation fragments/code

from a superclass.

• Interface Inheritance• Interface Inheritance– inheritance of contract fragments/interfaces.

The Complexities of Subclassing

• Methods of a class may freely invoke each other.

• Subclasses may override inherited methods.

• Subclass methods may call methods of • Subclass methods may call methods of superclasses, including overridden superclass methods.

• This is actually a form of “callback” from subclass to superclass.

Inheritance Issues Example

Text-text: Array of Char-used:Integer = 0-caret:Integer = 0

+max( ):Integer+length( ):Integer+write(pos:Integer, ch:Char)

+setCaret(pos:Integer)

-cacheX: Integer = 0-cacheY: Integer = 0

SimpleText

+write(pos:Integer, ch:Char)+delete(pos:Integer)+caretPos( ):Integer+setCaret(pos:Integer)posToXCoord(pos:Integer):IntegerposToYCoord(pos:Integer):IntegerposFromCoord(x:Integer,

y:Integer):Integer+type(Char)+rubout( )

+setCaret(pos:Integer)+posToXCoord(pos:Integer):Integer+posToYCoord(pos:Integer):Integer+posFromCoord(x:Integer,

y:Integer):Integer+hideCaret( )+showCaret( )

Example--Continuedabstract class Text {

.

.

.private int caret = 0;

.

.

class SimpleText extends Text {...

void setCaret(int pos) {int old = caretPos( );if (old != pos) {.

.void setCaret(int pos) {caret = pos;}

.

.

.}

if (old != pos) {hideCaret( );super.setCaret(pos);showCaret( );

}...

}

Example--ContinuedInteraction diagram resulting from call to method type of Text class:

Text SimpleText Display

typecaretPos

writesetCaretsetCaret

hideCaret

(update display)Super.setCaret

showCaret

setCaret

Example--ContinuedA new version of Text class that “breaks” the subclass SimpleText:

abstract class Text {...

void write (int pos, char ch) {int i;int i;for ( i = used; i > pos; i--)

text[i] = text[i-1];used = used + 1;if (caret >= pos)

caret = caret +1;text[pos] = ch;

}...

Inheritance Issues--The Fragile Base Class Problem

• There is an implicit interface between a class and its ancestor classes (superclasses).– Syntactic aspect--Does a class need to be

recompiled due to purely syntactic changes recompiled due to purely syntactic changes among it superclasses?

– Semantic Aspect--How dependent is a subclass upon changes in the implementation of its superclasses?

Dealing With Class-Subclass Dependencies

• Specialization Interface– Interface between a class and its subclasses

– For Java and C++, the specialization interface consists of the public and protected interface of the superclass.

• Various methods have been proposed to control behavior across a specialization interface, but these are largely of theoretical interest.

Alternatives to Inheritance--Object Composition

• Object composition--composition of behavior based upon references among objects rather than inheritance relations.

• Based upon “part of” relationship among • Based upon “part of” relationship among objects.– Suppose object A requests help from object B

– B is “part of” A if references to B do not leave A.

Object Composition

B

innerouter(owning)

CA(owned)objects

(owning)object

Note: A reuses the implementation of objects B and C

Composition Versus Inheritance

• An instantiated object has one notion of self even though it may inherit parts of its implementation from several superclasses.

• “Self-recursive” invocations of methods always return to the overriding version in always return to the overriding version in the lowest level subclass

• Composed objects do not have a common self—i.e.outer object does not share identity with inner objects.

Example of self-recursive calls

BaseA( )

Sub

Base SubSubSub

A( )

uses A( )

B( )

super.A( )super.A( )usesSub

A( )

SubSubA( )

super.A( )usessuper.A( )

usessuper.A

Example of Composition

BaseA”( )B( )

uses

:Base:SubSub :Sub

AA’

A’’

SubA’( )

SubSubA( )

uses

uses

Composition--Additional Observations• Composition requires that object

interactions, including recursive interactions among objects, be explicitly designed-in rather than an implicit by-product of implementation inheritance.implementation inheritance.

• Composition is a relationship between instantiated objects, not a relationship between classes.

• Composition can be made as general as subclassing by use of delegation.

Inheritance versus CompositionAn example of multiple inheritance from

a well-known OO textAPPLE PIE

APPLE PIE

Does this make sense?

Apple Pie Example-Continued

A more sensible approach

APPLE PIE

APPLE

1

*PIE SHELL

1

1

Apple Pie example--A Compositional Perspective

Apple Pie

Pie ShellApple

Inheritance Versus Composition--Another Example

• Inheritance is generally not appropriate for “is a role played by” relationships.

• For instance, consider roles in an airline reservation system:reservation system:– passenger

– ticket agent

– flight crew

– etc.

Roles Example--A Potential Inheritance Hierarchy

Person

CrewMember TicketAgent Passenger

Is there a problem with this approach?

Roles Example--A Potential Inheritance Hierarchy

Person

CrewMember TicketAgent Passenger

Problem with this approach: a person may play different roles. An instantiated subclass can only represent one role.

Roles Example--An Attempt to Fix the Inheritance Hierarchy

Person

CrewMember Passenger TicketAgentCrewMember Passenger TicketAgent

CrewMemberAndTicketAgent

CrewMemberAndPassenger

TicketAgentAndPassenger

CrewMemberAndTicketAgentAndPassenger

Roles Example--A More Rational Solution using Composition

CrewMember TicketAgent Passenger

Uses Uses Uses0..1 0..1 0..1

Person

Uses Uses Uses

1 1

1

Note: Many authors refer to this as delegation.

TicketAgentObject

PassengerObject

Object Encapsulation via Composition

PersonObject

PersonObject

An Alternative Composition for the Roles Example

CrewMember TicketAgent Passenger

Uses Uses Uses0..1 0..1 0..1

Person

Uses Uses Uses

1 1

1

Object Encapsulation for Alternative Composition

PersonPerson

PassengerTicketAgent Flight

CrewTicketAgent

Inheritance Versus Composition--Some Guidelines

• It is generally not a good idea to use inheritance for the following purposes:– To represent dynamically changing alternative roles of

a superclass

– To hide methods or attributes inherited from a – To hide methods or attributes inherited from a superclass (restriction)

– To implement a domain-specific class as a subclass of a utility class (specialization)

– Purely for purposes of obtaining functionality needed to implement the subclass (implementation inheritane)/

Potential Drawbacks of Composition (Delegation)

• There may be some minor performance penalty for invoking an operation across object boundaries as opposed to using an inherited method.inherited method.

• Composition can’t be used with partially abstract (uninstantiable) classes

• Composition does not, in and of itself, impose any disciplined structure on the design (but neither does a class hierarchy).

A Critical Look at Inheritance

“You can choose your associates, “You can choose your associates, but you’re stuck with your

ancestors.”

Inheritance in OOD

• Inheritance is often held to be sacrosanct in OOD.

• Tendency for OO developers to gauge the success of their efforts by the complexity of their inheritance hierarchy.their inheritance hierarchy.

• It is interesting to note that inheritance hierarchy examples in OO texts seldom deal with software design problems.

Inheritance--The Reality• Inheritance is a complex issue.

– Many different types of inheritance relationships.

– Basic notions differ among OO languages

– Some controversial issues--e.g. multiple inheritance.

– Inheritance can break encapsulation.– Inheritance can break encapsulation.

– Poorly conceived inheritance relationships can frustrate system reliability, maintainability, and evolvability.

• Inheritance is neither inherently good or bad. It must be used in a disciplined manner.

Inheritance--A Simple Classification

• Subclassing– inheritance of implementation fragments/code

from a superclass.

• Interface Inheritance• Interface Inheritance– inheritance of contract fragments/interfaces.

The Complexities of Subclassing

• Methods of a class may freely invoke each other.

• Subclasses may override inherited methods.

• Subclass methods may call methods of • Subclass methods may call methods of superclasses, including overridden superclass methods.

• This is actually a form of “callback” from subclass to superclass.

Inheritance Issues Example

Text-text: Array of Char-used:Integer = 0-caret:Integer = 0

+max( ):Integer+length( ):Integer+write(pos:Integer, ch:Char)

+setCaret(pos:Integer)

-cacheX: Integer = 0-cacheY: Integer = 0

SimpleText

+write(pos:Integer, ch:Char)+delete(pos:Integer)+caretPos( ):Integer+setCaret(pos:Integer)posToXCoord(pos:Integer):IntegerposToYCoord(pos:Integer):IntegerposFromCoord(x:Integer,

y:Integer):Integer+type(Char)+rubout( )

+setCaret(pos:Integer)+posToXCoord(pos:Integer):Integer+posToYCoord(pos:Integer):Integer+posFromCoord(x:Integer,

y:Integer):Integer+hideCaret( )+showCaret( )

Example--Continuedabstract class Text {

.

.

.private int caret = 0;

.

.

class SimpleText extends Text {...

void setCaret(int pos) {int old = caretPos( );if (old != pos) {.

.void setCaret(int pos) {caret = pos;}

.

.

.}

if (old != pos) {hideCaret( );super.setCaret(pos);showCaret( );

}...

}

Example--ContinuedInteraction diagram resulting from call to method type of Text class:

Text SimpleText Display

typecaretPos

writesetCaretsetCaret

hideCaret

(update display)Super.setCaret

showCaret

setCaret

Example--ContinuedA new version of Text class that “breaks” the subclass SimpleText:

abstract class Text {...

void write (int pos, char ch) {int i;int i;for ( i = used; i > pos; i--)

text[i] = text[i-1];used = used + 1;if (caret >= pos)

caret = caret +1;text[pos] = ch;

}...

Inheritance Issues--The Fragile Base Class Problem

• There is an implicit interface between a class and its ancestor classes (superclasses).– Syntactic aspect--Does a class need to be

recompiled due to purely syntactic changes recompiled due to purely syntactic changes among it superclasses?

– Semantic Aspect--How dependent is a subclass upon changes in the implementation of its superclasses?

Dealing With Class-Subclass Dependencies

• Specialization Interface– Interface between a class and its subclasses

– For Java and C++, the specialization interface consists of the public and protected interface of the superclass.

• Various methods have been proposed to control behavior across a specialization interface, but these are largely of theoretical interest.

Alternatives to Inheritance--Object Composition

• Object composition--composition of behavior based upon references among objects rather than inheritance relations.

• Based upon “part of” relationship among • Based upon “part of” relationship among objects.– Suppose object A requests help from object B

– B is “part of” A if references to B do not leave A.

Object Composition

B

innerouter(owning)

CA(owned)objects

(owning)object

Note: A reuses the implementation of objects B and C

Composition Versus Inheritance

• An instantiated object has one notion of self even though it may inherit parts of its implementation from several superclasses.

• “Self-recursive” invocations of methods always return to the overriding version in always return to the overriding version in the lowest level subclass

• Composed objects do not have a common self—i.e.outer object does not share identity with inner objects.

Example of self-recursive calls

BaseA( )

Sub

Base SubSubSub

A( )

uses A( )

B( )

super.A( )super.A( )usesSub

A( )

SubSubA( )

super.A( )usessuper.A( )

usessuper.A

Example of Composition

BaseA”( )B( )

uses

:Base:SubSub :Sub

AA’

A’’

SubA’( )

SubSubA( )

uses

uses

Composition--Additional Observations• Composition requires that object

interactions, including recursive interactions among objects, be explicitly designed-in rather than an implicit by-product of implementation inheritance.implementation inheritance.

• Composition is a relationship between instantiated objects, not a relationship between classes.

• Composition can be made as general as subclassing by use of delegation.

Inheritance versus CompositionAn example of multiple inheritance from

a well-known OO textAPPLE PIE

APPLE PIE

Does this make sense?

Apple Pie Example-Continued

A more sensible approach

APPLE PIE

APPLE

1

*PIE SHELL

1

1

Apple Pie example--A Compositional Perspective

Apple Pie

Pie ShellApple

Inheritance Versus Composition--Another Example

• Inheritance is generally not appropriate for “is a role played by” relationships.

• For instance, consider roles in an airline reservation system:reservation system:– passenger

– ticket agent

– flight crew

– etc.

Roles Example--A Potential Inheritance Hierarchy

Person

CrewMember TicketAgent Passenger

Is there a problem with this approach?

Roles Example--A Potential Inheritance Hierarchy

Person

CrewMember TicketAgent Passenger

Problem with this approach: a person may play different roles. An instantiated subclass can only represent one role.

Roles Example--An Attempt to Fix the Inheritance Hierarchy

Person

CrewMember Passenger TicketAgentCrewMember Passenger TicketAgent

CrewMemberAndTicketAgent

CrewMemberAndPassenger

TicketAgentAndPassenger

CrewMemberAndTicketAgentAndPassenger

Roles Example--A More Rational Solution using Composition

CrewMember TicketAgent Passenger

Uses Uses Uses0..1 0..1 0..1

Person

Uses Uses Uses

1 1

1

Note: Many authors refer to this as delegation.

TicketAgentObject

PassengerObject

Object Encapsulation via Composition

PersonObject

PersonObject

An Alternative Composition for the Roles Example

CrewMember TicketAgent Passenger

Uses Uses Uses0..1 0..1 0..1

Person

Uses Uses Uses

1 1

1

Object Encapsulation for Alternative Composition

PersonPerson

PassengerTicketAgent Flight

CrewTicketAgent

Inheritance Versus Composition--Some Guidelines

• It is generally not a good idea to use inheritance for the following purposes:– To represent dynamically changing alternative roles of

a superclass

– To hide methods or attributes inherited from a – To hide methods or attributes inherited from a superclass (restriction)

– To implement a domain-specific class as a subclass of a utility class (specialization)

– Purely for purposes of obtaining functionality needed to implement the subclass (implementation inheritane)/

Potential Drawbacks of Composition (Delegation)

• There may be some minor performance penalty for invoking an operation across object boundaries as opposed to using an inherited method.inherited method.

• Composition can’t be used with partially abstract (uninstantiable) classes

• Composition does not, in and of itself, impose any disciplined structure on the design (but neither does a class hierarchy).

A Critical Look at Inheritance

“You can choose your associates, “You can choose your associates, but you’re stuck with your

ancestors.”

Inheritance in OOD

• Inheritance is often held to be sacrosanct in OOD.

• Tendency for OO developers to gauge the success of their efforts by the complexity of their inheritance hierarchy.their inheritance hierarchy.

• It is interesting to note that inheritance hierarchy examples in OO texts seldom deal with software design problems.

Inheritance--The Reality• Inheritance is a complex issue.

– Many different types of inheritance relationships.

– Basic notions differ among OO languages

– Some controversial issues--e.g. multiple inheritance.

– Inheritance can break encapsulation.– Inheritance can break encapsulation.

– Poorly conceived inheritance relationships can frustrate system reliability, maintainability, and evolvability.

• Inheritance is neither inherently good or bad. It must be used in a disciplined manner.

Inheritance--A Simple Classification

• Subclassing– inheritance of implementation fragments/code

from a superclass.

• Interface Inheritance• Interface Inheritance– inheritance of contract fragments/interfaces.

The Complexities of Subclassing

• Methods of a class may freely invoke each other.

• Subclasses may override inherited methods.

• Subclass methods may call methods of • Subclass methods may call methods of superclasses, including overridden superclass methods.

• This is actually a form of “callback” from subclass to superclass.

Inheritance Issues Example

Text-text: Array of Char-used:Integer = 0-caret:Integer = 0

+max( ):Integer+length( ):Integer+write(pos:Integer, ch:Char)

+setCaret(pos:Integer)

-cacheX: Integer = 0-cacheY: Integer = 0

SimpleText

+write(pos:Integer, ch:Char)+delete(pos:Integer)+caretPos( ):Integer+setCaret(pos:Integer)posToXCoord(pos:Integer):IntegerposToYCoord(pos:Integer):IntegerposFromCoord(x:Integer,

y:Integer):Integer+type(Char)+rubout( )

+setCaret(pos:Integer)+posToXCoord(pos:Integer):Integer+posToYCoord(pos:Integer):Integer+posFromCoord(x:Integer,

y:Integer):Integer+hideCaret( )+showCaret( )

Example--Continuedabstract class Text {

.

.

.private int caret = 0;

.

.

class SimpleText extends Text {...

void setCaret(int pos) {int old = caretPos( );if (old != pos) {.

.void setCaret(int pos) {caret = pos;}

.

.

.}

if (old != pos) {hideCaret( );super.setCaret(pos);showCaret( );

}...

}

Example--ContinuedInteraction diagram resulting from call to method type of Text class:

Text SimpleText Display

typecaretPos

writesetCaretsetCaret

hideCaret

(update display)Super.setCaret

showCaret

setCaret

Example--ContinuedA new version of Text class that “breaks” the subclass SimpleText:

abstract class Text {...

void write (int pos, char ch) {int i;int i;for ( i = used; i > pos; i--)

text[i] = text[i-1];used = used + 1;if (caret >= pos)

caret = caret +1;text[pos] = ch;

}...

Inheritance Issues--The Fragile Base Class Problem

• There is an implicit interface between a class and its ancestor classes (superclasses).– Syntactic aspect--Does a class need to be

recompiled due to purely syntactic changes recompiled due to purely syntactic changes among it superclasses?

– Semantic Aspect--How dependent is a subclass upon changes in the implementation of its superclasses?

Dealing With Class-Subclass Dependencies

• Specialization Interface– Interface between a class and its subclasses

– For Java and C++, the specialization interface consists of the public and protected interface of the superclass.

• Various methods have been proposed to control behavior across a specialization interface, but these are largely of theoretical interest.

Alternatives to Inheritance--Object Composition

• Object composition--composition of behavior based upon references among objects rather than inheritance relations.

• Based upon “part of” relationship among • Based upon “part of” relationship among objects.– Suppose object A requests help from object B

– B is “part of” A if references to B do not leave A.

Object Composition

B

innerouter(owning)

CA(owned)objects

(owning)object

Note: A reuses the implementation of objects B and C

Composition Versus Inheritance

• An instantiated object has one notion of self even though it may inherit parts of its implementation from several superclasses.

• “Self-recursive” invocations of methods always return to the overriding version in always return to the overriding version in the lowest level subclass

• Composed objects do not have a common self—i.e.outer object does not share identity with inner objects.

Example of self-recursive calls

BaseA( )

Sub

Base SubSubSub

A( )

uses A( )

B( )

super.A( )super.A( )usesSub

A( )

SubSubA( )

super.A( )usessuper.A( )

usessuper.A

Example of Composition

BaseA”( )B( )

uses

:Base:SubSub :Sub

AA’

A’’

SubA’( )

SubSubA( )

uses

uses

Composition--Additional Observations• Composition requires that object

interactions, including recursive interactions among objects, be explicitly designed-in rather than an implicit by-product of implementation inheritance.implementation inheritance.

• Composition is a relationship between instantiated objects, not a relationship between classes.

• Composition can be made as general as subclassing by use of delegation.

Inheritance versus CompositionAn example of multiple inheritance from

a well-known OO textAPPLE PIE

APPLE PIE

Does this make sense?

Apple Pie Example-Continued

A more sensible approach

APPLE PIE

APPLE

1

*PIE SHELL

1

1

Apple Pie example--A Compositional Perspective

Apple Pie

Pie ShellApple

Inheritance Versus Composition--Another Example

• Inheritance is generally not appropriate for “is a role played by” relationships.

• For instance, consider roles in an airline reservation system:reservation system:– passenger

– ticket agent

– flight crew

– etc.

Roles Example--A Potential Inheritance Hierarchy

Person

CrewMember TicketAgent Passenger

Is there a problem with this approach?

Roles Example--A Potential Inheritance Hierarchy

Person

CrewMember TicketAgent Passenger

Problem with this approach: a person may play different roles. An instantiated subclass can only represent one role.

Roles Example--An Attempt to Fix the Inheritance Hierarchy

Person

CrewMember Passenger TicketAgentCrewMember Passenger TicketAgent

CrewMemberAndTicketAgent

CrewMemberAndPassenger

TicketAgentAndPassenger

CrewMemberAndTicketAgentAndPassenger

Roles Example--A More Rational Solution using Composition

CrewMember TicketAgent Passenger

Uses Uses Uses0..1 0..1 0..1

Person

Uses Uses Uses

1 1

1

Note: Many authors refer to this as delegation.

TicketAgentObject

PassengerObject

Object Encapsulation via Composition

PersonObject

PersonObject

An Alternative Composition for the Roles Example

CrewMember TicketAgent Passenger

Uses Uses Uses0..1 0..1 0..1

Person

Uses Uses Uses

1 1

1

Object Encapsulation for Alternative Composition

PersonPerson

PassengerTicketAgent Flight

CrewTicketAgent

Inheritance Versus Composition--Some Guidelines

• It is generally not a good idea to use inheritance for the following purposes:– To represent dynamically changing alternative roles of

a superclass

– To hide methods or attributes inherited from a – To hide methods or attributes inherited from a superclass (restriction)

– To implement a domain-specific class as a subclass of a utility class (specialization)

– Purely for purposes of obtaining functionality needed to implement the subclass (implementation inheritane)/

Potential Drawbacks of Composition (Delegation)

• There may be some minor performance penalty for invoking an operation across object boundaries as opposed to using an inherited method.inherited method.

• Composition can’t be used with partially abstract (uninstantiable) classes

• Composition does not, in and of itself, impose any disciplined structure on the design (but neither does a class hierarchy).