Engr 691-12: Special Topics in Engineering Science
Software Architecture
Fall Semester 2000
Lecture Notes

Understanding Inheritance (Budd's UOOPJ, Ch. 8)

This is a set of "slides" to accompany chapter 8 of Timothy Budd's textbook Understanding Object-Oriented Programming with Java (Addison-Wesley, 1998).

Motivation for Inheritance

Use inheritance to create new software structures from existing software units to:

• improve productivity

• enhance quality

Generality and Specialization in Software Development

Conflict:

• Specific projects usually require very specialized software

• Reusability usually requires very general software

Resolution?

• Inheritance allows general software to be specialized for a project

Abstract Idea of Inheritance

The abstract idea of inheritance is the grouping of "objects" into a hierarchy of categories.

Material_Object
        Non-Living_Thing
                Rock
                Air
        Living_Thing
                Plant
                Animal
                        Reptile
                        Mammal
                                Human_Being
                                        Dentist
                                                Roy
                                        Shopkeeper
                                                Flo
                                        Writer
                                                John
                                Cat
                                Dog
                                Platypus

Practical Meaning of Inheritance

In programming languages, inheritance means:

• Data and behavior of parent class are part of child

• Child class may include data and behavior not in parent

With respect to the parent class, a child class is, in some sense:

• an extension -- larger set of properties

• a contraction -- more specialized (restricted) objects

Idealized Image of Inheritance

Consider:

• Subclass instances must possess all data areas of the parent

• Subclass instances must implement all functionality of the parent

Thus:

• Subclass instance should be indistinguishable from parent class instance -- child can be substituted for parent

Principle of Substitutability:

If C is a subclass of P, instances of C can be substituted for instances of P in any situation with no observable effect.

Subclass, Subtype, and Substitutability

Subtype:

class that satisfies principle of substitutability

Subclass:

something constructed using inheritance, whether or not it satisfies the principle of substitutability.

The two concepts are independent:

• Not all subclasses are subtypes

• Sometimes subtypes are constructed without being subclasses

Forms of Inheritance

Specialization:

Child class is a special case (subtype) of parent

• Most common form of inheritance

• Example: Professor is specialized form of Employee

• Child may override behavior of parent to specialize

• Child satisfies specification of parent in all relevant aspects

• Preserves substitutability

Specification:

Parent class defines behavior implemented in the child, but not parent

• Second next most common form of inheritance

• Example: class StackInArray gives implementations for method signatures defined in abstract class Stack

  Java: StackInArray extends Stack

• Example: class ArrayRankedSeq gives implementations for method signatures defined in interface RankedSequence

  Java: ArrayRankedSeq implements RankedSequence

• Subclasses are realizations of incomplete abstract specification

• Defines common interface for group of related classes

• Preserves substitutability

Construction:

Parent class used only for its behavior -- child class is not subtype -- no is-a relationship to parent

• Sometimes used for convenience, but discouraged

• Example: extending List class to develop Set, without "hiding" unneeded methods

• Example: extending a byte-based I/O stream to a stream for handling other objects

• Often violates substitutability

• More common in dynamically typed languages (e.g., Smalltalk) than in statically typed (e.g., Java)

• Can sometimes use aggregation instead

Generalization:

Child class modifies or overrides some methods of parent, extends the behavior to more general kind of object

• Sometimes used for convenience (or necessity), but discouraged

• Example: graphics Window generalized to ColorWindow (with background color)

• Opposite of specialization -- violates substitutability

• Used when must build from fixed, difficult-to-modify set of classes

• Where possible, invert class hierarchy or use aggregation

Extension:

Child class adds new functionality to parent, but does not change any inherited behavior

• Useful technique to give new behaviors to existing base class that cannot be modified

• Example: StringSet extends Set, adding string-related methods (e.g, prefix search)

• Preserves substitutability

Limitation:

Child class limits some of the behavior of parent

• Sometimes used for convenience, but strongly discouraged

• Example: Stack extends DoubleEndedQueue, replacing unneeded methods to give error messages

• Violates substitutability

• Used when must build from fixed, difficult-to-modify set of classes

• Avoid when possible, perhaps use aggregation

Variance:

Child and parent class are variants of each other -- inheritance to allow code sharing -- arbitrary relationship

• Sometimes used for convenience, but discouraged

• Example: graphics Tablet class extending Mouse to share similar control code

• Violates substitutability

• Better to define more general parent class like PointingDevice

Combination:

Child class inherits features from more than one parent -- multiple inheritance

• Example: GraduateInstructor might inherit from both GraduateStudent and Faculty

• Often difficult to understand and to implement language

• Often use to "mix-in" specification of another role or protocol

• Java has single inheritance via subclassing (extends), but multiple inheritance for specification via interface implementations (implements)

Inheritance and Assertions

Suppose C is a subtype of P:

• P and C have interface invariants I and IC, respectively

• meth() is a public method of P with precondition Q and postcondition R

• meth() in C has precondition QC and postcondition RC

Subtype C should not violate I, Q, and R:

• IC implies I -- may strengthen invariant -- extend interface and data

• Q implies QC -- may weaken precondition -- expand valid inputs

• RC implies R -- may strengthen postcondition -- restrict valid outputs

Abstract preconditions can enable controlled "strengthening" of precondition

• Consider BoundedStack inheriting from an unbounded Stack class

• Give method push a "not full" precondition -- always true in Stack

• Refine "not full" in subclass BoundedStack to be true or false

public abstract class Stack 
{       // extends Object by default
	// data definitions plus signatures and
	//     possibly implementations of methods 
}

public class StackInArray extends Stack 
{	// extended features plus overridden implementations
}

public interface Queue 
{	// signatures of public methods Queues must provide
}

public class QueueAsLinkedList implements Queue 
{	// includes implementations of the Queue methods
}