Engr 691-10: Special Topics in Engineering Science
Software Architecture
Spring Semester 2002
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, Updated Edition (Addison-Wesley, 2002).

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

Trees versus Forests

There are two common views of class hierarchies.

Tree:

all classes part of single class hierarchy

Advantage:

root's functionality inherited by all objects -- all have basic functionality

Disadvantage:

tight coupling of classes, large libraries for an application

Languages: Java's classes, Smalltalk, Objective C, Delphi Object Pascal

Forest:

classes only placed in hierarchies if they have a relationship -- many small hierarchies.

Advantage:

smaller libraries of classes for application, less coupling possible

Disadvantage:

no shared functionality among all objects

Languages: Java's interfaces, C++, Apple Object Pascal

Inheritance in Java

Tree-structured class hierarchy

• Root class is Object

• Other classes extend exactly one other class -- default is Object

• Declaration uses keyword extends after class name

Forest-structured interface hierarchy

• interface defines an interface specification

• implements after class name to promise implementation of interface -- inheritance for specification

• An interface extends zero or more other interfaces

• A class implements zero or more interfaces

Modifiers for classes/interfaces

• abstract classes cannot be instantiated -- interfaces are abstract by default

• final classes cannot be extended

• public classes/interfaces are visible everywhere -- otherwise only visible within current package

Visibility modifiers for class/interface features

• public features accessible from anywhere in program

• private features accessible from inside class only

• default-access (i.e., "friendly") features accessible from inside the current Java package

• protected features accessible in package or inside any child class

Inheritance in Java

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
}

Facilities of Root Class Object

Minimum functionality for all objects include:

equals(Object obj)

is obj the same as receiver?

toString()

converts the object to a string value

hashCode()

return a default hashcode for the object

getClass()

return an identifier for the class of the object

The first three above are often overridden in classes.

Benefits of Inheritance

• Software reusability (among projects)

• Code sharing (within a project)

• Increased reliability (resulting from reuse and sharing of well-tested code)

• Consistency of interface (among related objects)

• Rapid prototyping (quickly assemble from pre-existing components)

• Polymorphism and frameworks (high-level reusable components)

• Information hiding

Costs of Inheritance

• Execution speed

• Program size

• Message-passing overhead

• Program complexity

UP to ENGR 691 Lecture Notes root document?