CSci 581: Obj.-Oriented Design & Programming
Spring Semester 1999
Lecture Notes

Mechanisms for Software Reuse (Budd's UOOPJ, Ch. 10)

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

Inheritance and Substitutability

Idealization of inheritance:

instance of "subclass" can substitute for instance of parent

In Java, substitutability by implementing interfaces as well as subclassing

Abstract concept captured with two rules of thumb:

is-a relation

"A dog is-a mammal" sounds right

Natural for dog to inherit from mammal

has-a relation

"A car is-a(n) engine" sounds wrong

Not natural to use inheritance

But "a car has-a(n) engine" sounds right

Can use composition (aggregation)

Two Approaches to Software Reuse in OOP

inheritance

the is-a relationship

• Useful when the new software component has all the behavior of the existing component, plus more.

• Inheritance of just specification or of code as well

• If "new-thing is-a old-thing" sounds reasonable, then inheritance can be used

composition (aggregation)

the has-a relationship

• Useful when the new software component builds on an existing system but differs fundamentally from the existing system

• If "new-thing has-a old-thing" sounds reasonable, then composition can be used

Example -- Building Sets from Lists

Suppose already have List data type with the following behavior:

class List 
{   public List() { ... }
    public void add(int) { ... }
    public void remove(int) { ... }
    public boolean includes(int) { ... }
    public int firstElement() { ... }
    ...
}

Wish to build Set data type -- elements are unique and unordered in set

Using Inheritance

class Set extends List 
{   public void add(int) { ... }
}

• Only need specify what is new -- add method overrides the one in List

• Everything else stays the same as in List

• Inherits unneeded firstElement operation

• Set potentially substitutable for List

Using Composition (Aggregation)

class Set 
{   public Set() { ... data = new List(); ... }
    public void add(int) { ... }
    public void remove(int) { ... }
    public boolean includes(int) { return data.includes(int); }
    private List data;
}

• Note data field of type List

• Redefine all operations -- except unneeded operation firstElement()

• May use List operations on data field

• Set not substitutable for List

Comparison of Inheritance and Composition

Advantages of inheritance over composition:

• shorter code
• increased functionality (thru polymorphism)
• sometimes less execution overhead

Advantages of composition over inheritance:

• easier to see and understand functionality (no "yo-yo" effect)
• inappropriate operations on constituent ("parent") type hidden
• easier to change to different constituent type

Combining Inheritance and Composition

Java API class InputStream

• Abstract concept of an input stream

• Concrete realizations differ by source of data values, each substitutable for parent
  • ByteArrayInputStream
  • FileInputStream
  • PipedInputStream
  • SequenceInputStream
  • StringBufferInputStream

• Also filters (or wrappers) for input streams that specify processing of data, both inheriting from and having InputStream component
  • FilterInputStream
    • gets data from its component InputStream of any type
    • but also substitutable for InputStream

• Note two orthogonal sources of variation -- data source and processing

Dynamic Composition

An advantage of composition over inheritance is delay in binding time -- parent/child inheritance at compile time

class Frog
{   public Frog() { behavior = new TadpoleBehavior(); }

    public grow()   // see if behavior should change
    {   if (behavior.growUp()) { behavior = new AdultFrogBehavor(); }
        behavior.grow();  // behavior does actual work
        behavior.swim();
    }

    private FrogBehavior behavior;
}

abstract class FrogBehavior
{   public void grow();
    public void swim();
    public boolean growUp() { return false;  }
}

class TadpoleBehavior extends FrogBehavior
{   public void grow() { ... }
    public void swim() { ... }
    public boolean growUp() { age++;  return (age > 24); }

    private int age = 0;
}

class AdultFrogBehavior extends FrogBehavior
{   public void grow() { ... }
    public void swim() { ... }
}

• Frog delegates its work to component FrogBehavior object

• Polymorphic variable behavior holds current FrogBehavior object

• Different FrogBehavior classes for differing behaviors (tadpole or adult)

• Frog object modifies behavior component when change needed (from tadpole to adult at proper age)

• Polymorphism means correct grow() and swim() methods called for current stage

• Frog object (interface) unchanged throughout life, but actual behavior changed as needed

Will Widespread Software Reuse Become Reality?

Even with the right mechanisms, software reuse not guaranteed to occur

Also need the right culture:

• Solid reusable component libraries

• Guidelines for producing reusable components

• Appropriate training of programmers for reuse

• Willingness of programmers to reuse

• Willingness of managers to pay for development of reusable components

• Patience and long-term dedication to reuse

UP to CSCI 581 Lecture Notes root document?