Modeling with abstraction - PowerPoint PPT Presentation

Loading...

PPT – Modeling with abstraction PowerPoint presentation | free to view - id: 17b25f-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Modeling with abstraction

Description:

Abstract classes are for structuring the system design rather than for providing ... It's harder to maintain inheritance based code than composition based code. ... – PowerPoint PPT presentation

Number of Views:12
Avg rating:3.0/5.0
Slides: 40
Provided by: hyperspace
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: 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
About PowerShow.com