Chapter 11 : Modeling with Abstraction

1
Chapter 11 Modeling with Abstraction
2
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.

3
Abstract classes

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

4
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.

5
Abstract classes

• An abstract class is a 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.

6
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.

7
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.

8
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.

9
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.

10
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

11
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.

12
Interfaces, abstract classes, concrete classes
public boolean isIn (Location point, Depictable
figure) Location l figure.location() Dimens
ion d figure.dimension()

• Can pass instances of WordBalloon to isIn.

13
Specifying a class for extension

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

14
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
15
abstract class AbstractPlayer implements Player
private String name private int sticksTaken
//subclasses update it. public AbstractPlayer
(String name) this.name name this.sticksT
aken 0 public String name () return
this.name public int sticksTaken ()
return this.sticksTaken public String
toString () return "Player " name ",
took " sticksTaken
16
TimidPlayer definition via inheritance
class TimidPlayer extends AbstractPlayer
public TimidPlayer (String name) super(name)
public void takeTurn (Pile pile, int
maxOnATurn) pile.remove(1) this.sticksTaken
1 // updates of AbstractPlayer //
instance variable.

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

17
Protected instance variables
abstract class AbstractPlayer implements Player
private String name protected int
sticksTaken

• Now TimidPlayer has access to AbstractPlayer
  instance variable sticksTaken.

18
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.

19
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.

20
Planning for extension
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
21
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)
22
Planning for extension
public class ThreeDigitLock public void
enterCombination (int combination) int
remainder combination int position
100 while (position gt 0) ¹ enterDigit(remai
nder / position) remainder remainder
position position position / 10

• Problem ThreeDigitLocks enterCombination method
  is implementing by invoking enterDigit three
  times.

23
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.

24
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
25
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 .

26
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)
27
Planning for extension

• Prevent extension of a class by declaring its
  constructor private.
• private constructor lets us control the
  conditions under which an instance will be
  created.

public class Singleton private static
Singleton instance null // constructor can
be invoked only //from inside
class. private Singleton () public static
Singleton getInstance () // if one
doesnt already exist, create it. if
(instance null) instance new
Singleton() return instance
28
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.

29
Class extension OR class composition?
30
Class extension v.s. class composition
Reused class Resulting class
Extension superclass subclass
Composition core class composed class
31
Class extension v.s. class composition

• Two advantages of class extension
• code reuse
• polymorphism.
• Disadvantages of class extension
• Changes to a superclass specification propagate
  to clients and subclasses
• classes are not always designed and documented
  for extension.
• a subclass is committed to maintain
  specifications inherited from its superclass.

32
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.

33
Class extension v.s. class composition

• InstrumentedLock does not depend on
  implementation of ThreeDigitLock.

34
Class extension v.s. class composition

• Composition can add functionality to an object.

35
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.

36
Extension, composition, and modifying
functionality

• Poor use of extension to model roles objects
  play.
• Results in awkward constructions in which
  detailed knowledge of an objects possible roles
  is spread throughout the application.

37
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.

38
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 as a component.
• Problem change Player role to Dealer role (and
  vice-versa).
• Solution Dealer can be assigned Player at
  run-time.

39
Extension, composition, and modifying
functionality

• Poor use of extension provide alternate
  implementations of functionality.
• can lead to a combinatorial explosion in class
  hierarchy

AbstractPlayer
CleverPlayer
TimidPlayer

40
Extension, composition, and modifying
functionality

• Good use of composition provide alternate
  implementations of functionality.
• Bridge pattern Separate abstraction hierarchy
  from implementation hierarchy.

has implementation
SomeClass
Implementation
void
service()
void
service()
implementation.service()
Implementation1
Implementation2
41
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)
42
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)
43
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.

44
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.

45
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.

46
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.

47
State as an object
interface
classification
Student
Classification

Undergraduate
JuniorDivision