Chapter 11 : Modeling with Abstraction - PowerPoint PPT Presentation

Loading...

PPT – Chapter 11 : Modeling with Abstraction PowerPoint presentation | free to download - id: 71cad5-Mzc2N



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Chapter 11 : Modeling with Abstraction

Description:

Chapter 11 : Modeling with Abstraction Objectives After studying this chapter you should understand the following: the roles played by interfaces, abstract classes ... – PowerPoint PPT presentation

Number of Views:49
Avg rating:3.0/5.0
Slides: 57
Provided by: Emplo160
Learn more at: http://www.cs.uno.edu
Category:

less

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

Title: Chapter 11 : Modeling with Abstraction


1
Chapter 11 Modeling with Abstraction
2
Objectives
  • After studying this chapter you should understand
    the following
  • the roles played by interfaces, abstract classes,
    and concrete classes
  • the use of protected features for the benefit of
    subclasses
  • the two kinds of clients a class can have, and
    the additional documentation required by subclass
    clients regarding the implementation of
    superclass features
  • class extension and class composition, and their
    proper use.
  • Also, you should be able to
  • use abstract classes to specify class
    generalization
  • use interfaces, abstract classes, and concrete
    classes to model a system.

3
Review of Player interface
  • Interface Player implemented by several classes
  • classes are identical except for implementation
    of takeTurn.
  • classes contain considerable amount of duplicate
    code.

4
Abstract classes
  • AbstractPlayer can contain implementations of
    methods common to all Player variants,
  • name
  • sticksTaken
  • Player subclasses inherit these methods.

5
Abstract classes
  • An abstract class is a class that
  • can contain abstract methods,
  • cannot be instantiated.
  • used as basis on which to build classes by
    extension.

6
Abstract classes
  • An abstract class is class
  • Defines a type.
  • Occupies a position in the class hierarchy.
  • Can be the parent of other classes, abstract or
    not.
  • Has a unique parent which may or may not be
    abstract.
  • Has one or more constructors.
  • It can define nonabstract methods.
  • Has instance variables.
  • Concrete class a non-abstract class.

7
Abstract classes
  • An abstract method must be labeled abstract.

public abstract void takeTurn (Pile pile, int
maxOnATurn)
  • An abstract class can inherit abstract methods
  • From an interface, or
  • From a class.

8
Interfaces, abstract classes andconcrete classes
  • An interface
  • used to specify functionality required by a
    client.
  • An abstract class
  • provides a basis on which to build concrete
    servers.
  • A concrete class
  • completes server implementation specified by an
    interface
  • furnish run-time objects
  • not generally suited to serve as a basis for
    extension.

9
Nim game, Interfaces, abstract classes
andconcrete classes
  • In the nim game,
  • Interface Player defines functionality required
    by a player for the Game and user interface.
  • Abstract class AbstractPlayer contain
    implementation of methods common to all Player
    variants.
  • TimidPlayer, GreedyPlayer, ClerverPlayer,
    subclasses of AbstractPlayer, are concrete
    classes which complete implementation of Player
    interface.

10
Nim game, Interfaces, abstract classes
andconcrete classes
  • In the nim game,
  • Class Game is programmed using Player interface.
  • During execution, Game is provided with concrete
    instances of TimidPlayer, GreedyPlayer, or
    ClerverPlayer.

11
Abstract class use
  • An abstract class factors out implementation of
    its concrete subclasses.
  • Used to exploit polymorphism.
  • Functionality specified in parent class can be
    given implementations appropriate to each
    concrete subclass.
  • Abstract class must be stable.
  • any change in an abstract class propagates to
    subclasses and their clients.
  • A concrete class can only extend one (abstract)
    class

12
Interface use
  • Interfaces are by definition abstract.
  • separate an objects implementation from its
    specification.
  • 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 instances of relatively unrelated
    classes can be treated as identical for some
    specific purpose.

13
Interfaces, abstract classes, concrete classes
public boolean isIn (Location point, Depictable
figure) Location l figure.location() Dimens
ion d figure.dimenstion()
14
Interfaces, abstract classes, concrete classes
public boolean isIn (Location point, Depictable
figure) Location l figure.location() Dimens
ion d figure.dimenstion()
  • Can pass instances of WordBalloon to isIn.

15
Specifying a class for extension
  • Two class uses
  • A class can be a client to another class and use
    the other class as a server.
  • A class can also extend another class, using the
    other class as a basis for its implementation.

16
Specifying a class for extension
  • Clients and subclasses have different views of a
    class.

Needs to know only specification of SomeClass
Needs to know specification and implementation of
SomeClass
17
abstract class AbstractPlayer implements Player
private String name private int sticksTaken
//subclasses will update it. public
AbstractPlayer (String name) this.name
name this.sticksTaken 0 public String
name () return this.name public int
sticksTaken () return this.sticksTaken pu
blic String toString () return "Player "
name ", took " sticksTaken
18
class TimidPlayer extends AbstractPlayer
public TimidPlayer (String name)
super(name) public void takeTurn (Pile
pile, int maxOnATurn) pile.remove(1) this.s
ticksTaken 1 // update of AbstractPlayer

// instance variable.
  • Will not compile.
  • TimidPlayer has no access to AbstractPlayer
    instance variable sticksTaken.

19
abstract class AbstractPlayer implements Player
private String name protected int
sticksTaken
  • Now TimidPlayer has access to AbstractPlayer
    instance variable sticksTaken.

20
Specifying a class for extension
  • Root of problem between AbstractPlayer and
    TimidPlayer
  • subclass has a different, stronger relation to
    parent class than a client.
  • TimidPlayer needs to be able to tell
    AbstractPlayer store this sticksTaken value.
  • Subclasses needs a different contract with its
    parent than a client needs.
  • Use protected features to specify subclass
    contract.

21
Planning for extension
  • A subclass depends on the Parent implementation.
  • subclass often requires access to parents
    underlying implementation structure.
  • correctness of a subclass can depend on the
    algorithms used to implement parent methods.

22
Planning for extension
  • Class has methods that allow combination entered
    either digit by digit, or a single integer.

public class ThreeDigitLock A combination lock
with a three digit combination. public void
enterDigit (int digit) Enter a digit of the
combination lock unlocks if the three digits
of the combination are entered in
order. require 0 lt digit digit lt
9 public void enterCombination (int
combination) Enter the three digit combination
specified lock unlocks if the three digits of
the combination are entered in order. require
0 lt combination combination lt 999
23
Planning for extension
  • Build lock that keeps track of total number of
    digits entered.

public class InstrumentedLock extends
ThreeDigitLock private int digitCount publ
ic void enterDigit (int digit) digitCount
digitCount 1 super.enterDigit(digit) pub
lic void enterCombination (int combination)
digitCount digitCount 3 super.enterComb
ination(combination)
24
Planning for extension
  • Problem ThreeDigitLocks enterCombination method
    is implementing by invoking enterDigit three
    times

public class ThreeDigitLock public void
enterCombination (int combination) int
remainder combination int position
100 while (position gt 0) ¹ enterDigit(rema
inder / position) remainder remainder
position position position / 10
25
Planning for extension
  • Due to implementation of enterCombination in
    ThreeDigitClass class, InstrumentedLock should
    not increment digitCount.
  • InstrumentedLock subclass design depends on
    ThreeDigitClasss algorithm used in
    enterCombination.
  • ThreeDigitLock must document method
    implementation.

26
Planning for extension
public void enterCombination (int
combination) Enter the three digit combination
specified lock unlocks if the Three digits of
the combination are entered in order. This
implementation invokes enterDigit three times,
once for each digit in the specified
combination. require 0 lt combination
combination lt 999
27
Planning for extension
  • General rules to design classes for extension
  • Document any internal use of classs overridable
    methods.
  • Constructors should not invoke classs
    overridable methods .

28
Planning for extension
  • Prevent class extension by declaring a class
    final.

public final class ThreeDigitLock
  • Prevent method overriding by declaring method
    final.

public final void enterCombination (int
combination)
29
Composition revisited
  • Uses of composition
  • a component is an intrinsic part of an object.
  • a class formed as an aggregation of components,
    where components exist independently of
    aggregation.
  • to wrap an existing class in order to alter its
    interface.

30
Class extension and class composition
31
Class extension OR class composition?
32
Class extension v.s. class composition
Reused class Resulting class
Extension superclass subclass
Composition core class composed class
33
Class extension v.s. class composition
  • Two advantages of class extension
  • code reuse
  • polymorphism.

34
Class extension v.s. class composition
  • Disadvantages of class extension
  • Changes to a superclass specification propagate
    to clients and subclasses

35
Class extension v.s. class composition
  • Other disadvantages of class extension
  • classes are not always designed and documented
    for extension.
  • a subclass is committed to maintain
    specifications inherited from its superclass.

36
Class extension v.s. class composition
  • Advantages of composition
  • Existing classes can be used in composed classes.
  • Can change objects behavior dynamically.
  • Supports stronger encapsulation than does
    inheritance.
  • Can change specification of composed class
    without changing core.
  • Composed class depends only on specification of
    core class, not on its implementation.
  • Implementation changes in core class do not
    propagate to composed class.

37
Class extension v.s. class composition
  • InstrumentedLock does not depend on
    implementation of ThreeDigitLock.

38
Class extension v.s. class composition
  • Composition can add functionality to an object.

39
Class extension v.s. class composition
  • Conclusion
  • reuse through composition produces more flexible
    code.
  • must not ignore advantages of polymorphism via
    inheritance.
  • lose polymorphism with composition.
  • But can gain it back by composing with interfaces
    and defining core classes that implement them.

40
Extension, composition, and modifying
functionality
  • Poor use of extension to model roles objects
    play.
  • result in awkward constructions in which detailed
    knowledge of an objects possible roles is spread
    throughout the application.

41
Extension, composition, and modifying
functionality
  • Poor use of extension model roles objects may
    play.
  • Example model card player, and card dealer.
  • Solution
  • specify Player
  • use extension to specify Dealer.
  • Problem change Player role to Dealer role (and
    vice-versa).
  • Solution (Ackward) Make any Player an instance
    of Dealer. Switch roles via Dealer state
    condition.

42
Extension, composition, and modifying
functionality
  • Good use of composition to model roles objects
    may play.
  • Example model card player, and card dealer.
  • Solution
  • specify Player
  • specify Dealer having a Player instance as a
    component.
  • Problem change Player role to Dealer role (and
    vice-versa).
  • Solution Dealer instance can be assigned object
    Player at run-time.

43
Extension, composition, and modifying
functionality
  • Poor use of extension provide alternate
    implementations of functionality.
  • can lead to a combinatorial explosion in class
    hierarchy

44
Extension, composition, and modifying
functionality
  • Good use of composition provide alternate
    implementations of functionality.
  • Bridge pattern Separate abstraction hierarchy
    from implementation hierarchy.

45
Extension and object state
  • Kind of thing object models and object state
    are related.
  • Model several categories of students junior
    division students, undergraduates, graduate
    students, etc.

public class Student // Student
classifications public static final int
JUNIOR_DIVISION 0 public static final int
UNDERGRADUATE 1 public static final int
GRADUATE 2 private int classification pub
lic int classification () public void
setClassification (int class)
46
Extension and object state
  • Some of the functionality of a Student is state
    dependent.
  • Code depending on students classification via
    case analysis.

int classification someStudent.classification()
if (classification Student.JUNIOR_DIVISION)
handle JUNIOR_DIVISION case else if
(classification Student.UNDERGRADUATE)
handle UNDERGRADUATE case else if
(classification Student.GRADUATE)
47
Extension and object state
  • Problem with structure
  • method containing this code is dependent on
    student classifications.
  • such structured conditionals scattered throughout
    implementation.
  • maintenance complication adding new
    classification requires modifications in a number
    of places,.
  • long conditionals handling many cases are hard to
    understand and difficult to modify or extend.
  • Such structures are generally undesirable in an
    object-oriented system.

48
Extension and object state
  • Better structure subclass Student to model
    different classifications.
  • Classification-dependent behavior handled by
    providing different implementations in subclass
    methods.
  • New classification is handled by defining a new
    subclass.
  • Clients depend on polymorphism for appropriate
    behavior.

49
State as an object
  • Difficulty with subclassing classification.
  • Class of an object is fixed when the object is
    created.
  • Subclassing (static) does not support (dynamic)
    type transfer from one subclass to another.

50
State as an object
  • Better structuring of Student with classification
    that changes dynamically
  • Define interface isolating state-dependent
    behavior.
  • Equip object with a state-defining component that
    implements interface.
  • Different behaviors achieved by providing
    different subclasses for component.
  • State-dependent requests forwarded to state
    component.

51
State as an object
52
Summary
  • considered use abstraction and composition in the
    structure of a system design.
  • Introduced abstract classes.
  • can contain abstract methods,
  • cannot be instantiated.
  • contains an implementation component
  • Form part of a class hierarchy.
  • used as a foundation on which to build concrete
    classes.

53
Summary
  • Classes have two distinct kinds of customers
  • clients that use class through its specification.
  • subclasses that extend the class.
  • Different kinds of customers
  • have very different needs,
  • Require different class contracts.

54
Summary
  • Dependency of subclass on parent superclass
  • quite strong,
  • at the implementation level.
  • Good rule view only abstract classes and
    interfaces as suitable for extension.

55
Summary
  • Compared composition and extension.
  • could achieve alternate implementations either by
    extending class, or by providing class with a
    strategy component.
  • Functionality can be added to a class with
    extension or by wrapping.
  • Composition
  • fewer maintenance problems than extension.
  • produces a more flexible and maintainable
    structure than extension.
  • Extension
  • for legitimate, permanent is-a relation between
    classes,
  • specification of the superclass is stable.

56
Summary
  • Object state can be modeled with extension.
  • Cases where object can dynamically change state,
    use composition with state component structured
    via inheritance
About PowerShow.com