Modeling with abstraction

1
Chapter 14

• Modeling with abstraction

2
This chapter discusses

• The role of abstract classes in system design and
  implementation.
• Java interfaces.
• Extension and composition for constructing
  classes.
• Guidelines on class design and implementation.

3
Abstract classes

• Abstract classes are used as a basis from which
  to build extensions.
• Abstract classes are for structuring the system
  design rather than for providing run-time
  objects.

4
Abstract class guidelines

• An abstract class should be used to model a
  generalized object, not simply to capture common
  functionality.
• The decision to generalize must be made with
  care any change to an abstract class propagates
  to its descendants and their clients.
• An abstract class should factor out common
  implementation details of its concrete
  subclasses.
• Abstraction provides opportunities to exploit
  polymorphism.

5
Interface

• An interface in Java is much like an abstract
  class, but with no constructors, method bodies,
  or component variables.
• Contains only method specifications (abstract
  methods) and named constant definitions.

6
Interface (cont.)

• Example The package java.awt
• public interface LayoutManager
• Dimension minimumLayoutSize (Container parent)
• Dimension preferredLayoutSize (Container
  parent)
• void addLayoutComponent (String name, Component
  comp)
• void removeLayoutComponent (Component comp)
• void layoutContainer (Container parent)
• The methods are implicitly public.

7
Interface Implementation

• A class implements an interface in much the same
  way it extends an abstract class.
• Example
• public class FlowLayout implements
  LayoutManager

8
Extending Interfaces

• One interface can extend another interface in
  much the same way that one class can extend
  another class.
• Example
• public interface LayoutManager2 extends
  LayoutManager
• void addLayoutComponent (Component comp,
  Object constraints)
• Dimension maximumLayoutSize (Container target)
• float getLayoutAlignmentX (Container target)
• float getLayoutAilgnmentY (Container target)
• void invalidateLayout (Container target)
• / Any class that implements LayoutManager2
  must implement these five methods in addition to
  the five methods specified by LayoutManger. /

9
Multiple inheritance

• For interfaces only, inheritance can extend more
  than one parent.
• public interface DataIO extends
• DataInput, DataOutput

10
Multiple inheritance (cont.)

• public class RandomAccessFile
• implements DataInput, DataOutput

11
Reference-to-interface types

• We cannot directly create interface instances.
• We can create variables of type
  reference-to-interface.
• private LayoutManager mgr
• mgr new FlowLayout()

12
Reference-to-interface types (cont.)

• The same subtyping rules that hold for classes
  also hold for interfaces.
• LayoutManager2 mgr2 new BorderLayout()
• //BorderLayout implements LayoutManager2
• mgr mgr2//a LayoutManager2 is a
  //LayoutManager
• mgr2 mgr//Not legal! a LayoutManager is
• //not necessarily a
• //LayoutManger2

13
Interfaces vs. abstract classes

• Abstract classes
• The purpose of a class is to provide an
  implementation.
• An abstract class should be used to implement the
  generalization relationship, factoring out common
  implementation details from the subclasses.
• Concrete classes implement specific differences
  and extend functionality.
• Interfaces
• An interface defines only a specification.
• Two classes that implement the same interface are
  related only in that they support the same
  abstract functionality defined by the interface.

14
The advantages of interfaces over classes

• Interfaces are by definition abstract they do
  not fix any aspect of an implementation.
• A class can implement more than one interface.
• Interfaces allow a more generalized use of
  polymorphism, since instances of relatively
  unrelated classes can be treated identically for
  some specific purpose.

15
Interfaces, abstract classes, and modification

• The features found in an abstract class should be
  stable.
• The result of even a small change to an abstract
  class is substantial code modification and
  recompilation.
• This is not true for the addition of a feature
  with a default implementation provided in the
  abstract class (incremental programming).
• Interfaces are impossible to modify without
  requiring modification of all their
  implementations as well.

16
Interfaces and the software life-cycle

• Use of interfaces promotes higher reusability.
• Design an important method for abstraction
  serves as a stabilizing element in specifying and
  implementing classes.
• ImplementationThe compiler verifies that in a
  class implementing an interface, all methods of
  the interface are implemented with the correct
  specification.
• Integration Interfaces act as the glue for
  composed classes and subsystems.
• Testing Logical errors are limited to a subset
  of methods.

17
Interfaces vs. abstract classes

• Abstract classes are used to form hierarchies of
  implementations.
• Interfaces promote abstraction and reuse across
  class hierarchies.
• Interfaces specify only functionality and can
  extend one or more existing interfaces.

18

• Example
• public interface Depictable
• public Location getLocation ()
• public Dimension getDimension ()
• public abstract class GeometricalFigure
• implements Depictable
• public abstract Location getLocation ()
• public abstract Dimension getDimension()
• public class Rectangle extends
• GeometricalFigure

19

• public boolean isIn (Location point,
  Depictable figure)
• Location l figure.getLocation()
• Dimension d figure.getDimension()
• public class ArtClip
• public class WordBalloon extends ArtClip
  implements Depictable

20
Manipulating objects solely in terms of
specifications

• Clients remain independent of the specific types
  of the objects they manipulate
• Clients remain independent of the classes that
  implement these objects.
• (New) classes can be created/modified that
  implement an interface without affecting clients
  that depend solely on the interface.

21
Program to an interface, not to an implementation

• Write code that interacts not with the objects,
  but with possibly several distinct
  implementations of the interface of those objects.

22
Extension and composition

• Extension implements the is-a relation
  composition implements the has-a relation.

23
Extension and composition (cont.)
24
Extension and composition (cont.)

• A function objects only purpose is to provide
  the functionality implemented by a method.
• WarningSaying the purpose of an object is to do
  something is often a sign of faulty design. i.e.
  It probably doesnt need to be represented as an
  object, but rather a responsibility of some other
  more coherent object.

25
(No Transcript)
26

• interface MoveStrategy
• int numberToTake (Pile pile,
• int maximum)
• class Player
• public void setStrategy (MoveStrategy s)
• myStrategy s
• public MoveStrategy getStrategy ()
• return myStrategy
• public void makeMove (Pile pile, int
• maximum)
• int number myStrategy.numberToTake
  (pile, maximum)
• pile.remove(number)
• this.numberTaken number

27
Inheritance, composition and reuse

• reused class resulting class
• inheritance superclass subclass
• composition core class composed class

28
Inheritance, composition and reuse (cont.)

• The advantages of inheritance are
• code reuse
• polymorphism
• A superclass and subclass are strongly coupled.
• A change to a superclass specification affects
  its subclasses and their clients as well as its
  own clients.

29
Inheritance, composition and reuse (cont.)

• Composition also offers code reuse, since core
  classes can be used in the construction of a
  different composed class.
• It is possible to change an objects behavior
  dynamically at run time.
• It supports stronger encapsulation than
  inheritance.
• It is easy to change the specification of the
  composed class without effecting the core class.

30
Inheritance, composition and reuse (cont.)

• Modifying the reused class with inheritance is
  likely to affect more of the system than
  modifying the reused class with composition.
• Modifying the resulting class with composition
  does not affect the reused class.
• Modifying the resulting class with inheritance
  may not be feasible if the modification changes
  the specification of the inherited features.
• Reuse through composition produces more flexible
  code.

31
Inheritance, composition, and modifying
functionality

• Inheritance should not be used simply for code
  reuse or to take advantage of polymorphism.
• Its harder to maintain inheritance based code
  than composition based code.
• Interfaces can be employed to maintain separation
  between specification and implementation, and to
  provide reuse and polymorphism across class
  hierarchies.
• Composition can be used to provide alternate
  implementations of some specific functionality.

32
Extension and state

• The kind of thing an object models and the
  state of an object are closely related semantic
  notions.
• Example
• public class Student
• public static final int JR_DIVISION 0
• public static final int UNDERGRAD 1
• public static final int GRADUATE 2
• public int classification ()
• public void setClassification (int
  class)
• private int classification

33
Extension and state (cont.)

• Some of the functionality of a Student is state
  dependent.
• Example
• int classification s.classification()
• if (classification Student.JR_DIVISION)
• //handle JR_DIV case
• else if (classification
• Student.UNDERGRAD)
• //handle UNDERGRAD case
• else if (classification
• Student.GRADUATE

34
Extension and state (cont.)

• Adding a new classification requires modification
  in several places, complicating maintenance.
• Another approach is to model different
  classifications by subclassing rather than by
  including classification as part of the classs
  state.
• Classification-dependent behavior is handled by
  providing different implementations of common
  methods in each subclass.

35
A difficulty with subclassing

• The class of an object is fixed when the object
  is created.
• But, the class of an object may change over time
  (from Freshman to Sophomore, for example),
  necessitating the copying of information from the
  old object to the new object.
• Unfortunately, other elements of the system may
  still reference the old object.

36
A better approach

• Use composition rather than employing extension
  directly.
• Define an interface (or abstract class) that
  isolates state-dependent behavior.
• Equip an object with a "state-defining" component
  that implements the interface.
• Different behaviors are achieved by defining
  different subclasses.
• State transitions become explicit and can be
  delegated to the state subclasses.

37
Extension and state (cont.)

• public class Student
• public void register ()
• classification.register()
• private Classification classification

38
Weve covered

• Abstraction in the structure of system design.
• abstract classes
• interfaces
• Composition and extension.
• Modeling states of objects using extension.

39
Glossary