Chapter 9 1

Chapter 9Chapter 9

Object-Oriented Object-Oriented DesignDesign

Chapter 9 2

TopicsTopics

Class Design

Class Hierarchy Design

Designing Complex Logic

Design Representations

Design Patterns

Chapter 9 3

Class Design: Class Design: PerspectivesPerspectives

specification

Behavioral

Structural

Information

Chapter 9 4

Behavioral PerspectiveBehavioral Perspective

What objects initiate the action?What object collaborte in performing

the action?What objects are altered by the

performance of the action?What objects are interrogated during

the action?

Chapter 9 5

Behavioral ClassesBehavioral Classes

actor (does something)

reactor (system events, external events, user events)

agent (messenger, server, finder, communicator)

transformer (formatter, filter)

Chapter 9 6

Structual PerspectiveStructual Perspective

What objects are involved in the relationship?

What objects are necessary to sustain (implement, realize, maintain) the relationship?

What objects not in the relationship are aware of and exploit the relationship?

What objects not in the relationship are used by the related objects?

Chapter 9 7

Structural ClassesStructural Classes

acquaintance (symmetric, asymmetric)

containment (collaborator, controller)

collection (peer, iterator, coordinator)

Chapter 9 8

Information PerspectiveInformation Perspective

What objects are needed to represent the data or state?

What objects read the data or interrogate the state?

What objects write the data or update the state?

Chapter 9 9

Information ClassesInformation Classes

•source/sink

•query

•result

•buffer

•cache

•synchronizer

Data State

•recorder

•scheduler

•maintainer

Chapter 9 10

Evaluating a Class DesignEvaluating a Class DesignAbstraction : does the class capture a

useful abstractionResponsibilities : does the class bear a

reasonable set of responsbilitiesInterface : is the interface of the class clean

and simpleUsage : is the class design consistent with

how it is actually usedImplementtion : is there a reasonable

implementation for the class

Chapter 9 11

Evaluating AbstractionEvaluating Abstraction

Identity : does the class have a simple and suggestive name?

Clarity : can the meaning of the class be captured in a brief, dictionary-style definition?

Uniformity : do the methods have a similar level of abstraction?

Chapter 9 12

Evaluating Evaluating ResponsibilitiesResponsibilities

Clear : are the responsibilities of the class well-defined

Limited : do the responsibilities of the class exceed what is required for the abstraction captured by the class

Coherent : are all of the responsibilities of the class related to the same single abstraction

Complete : are there aspects of the abstraction that are missing from the class’s responsibilities

Chapter 9 13

Evaluating an InterfaceEvaluating an Interface

Naming : do the names of the class’s methods convey the method’s intended effect

Symmetry : do related methods have similar terminology and usage

Flexibility : are the method’s usable in different contexts or usage patterns

Convenience : are appropriate defaults available for common-case use

Chapter 9 14

Evaluating UsageEvaluating Usage

Can the class be reused outside of the immediate context for which it was developed? Is it sufficiently general-purpose?

Increasing the potential usage must be balanced against the possible loss in clearly capturing a single abstraction!

Chapter 9 15

Evaluating the Evaluating the ImplementationImplementation

Is there at least one clearly possible implementation for the class?

Are there a variety of possible implementations that trade-off resource (time vs. space) or non-functional (reliability, complexity) factors?

Chapter 9 16

Class Hierarchy DesignClass Hierarchy Design

Questions:

What are the dimensions of a class hierarchy?

How can a set of classes be factored into related groups that form the class hierarchy? How can this factoring be expressed?

Is there a process to use in forming a class hierarchy?

Chapter 9 17

Class Hierarchy Class Hierarchy DimensionsDimensions

Chapter 9 18

““Rationalizing” a Class Rationalizing” a Class HierarchyHierarchy

A class hierarchy is justified by a “rationalization” that reveals the categorization underlying the class hierarchy.

The word “rationalization” in this sense means to provide a “rational” (reasoned, principled) explanation for the hierarchy’s structure and organization.

Rationalizations aid in documenting and learning the hierarchy.

Chapter 9 19

A Rationalized HierarchyA Rationalized Hierarchy

Chapter 9 20

A Process to Design a A Process to Design a Class HierarchyClass Hierarchy

Iteratively perform these steps:

Analyze : study all of the classes with the same immediate parent class (or all classes at the beginning) looking for common and differentiating properties

Classify : divide into groups - all things in the same group have the same common properties, things in different groups have a discriminating property

Rationalize : create a base class for each group

Chapter 9 21

An ExampleAn Example

Chapter 9 22

First IterationFirst Iteration

Chapter 9 23

Second IterationSecond Iteration

Chapter 9 24

Third IterationThird Iteration

Chapter 9 25

Fourth IterationFourth Iteration

Chapter 9 26

Designing Complex LogicDesigning Complex Logic

Complex decision-making scenarios are difficult to:

state precisely

understand clearly

program correctly

design for extensibility

Section 9.4

Chapter 9 27

Designing Complex LogicDesigning Complex Logic

The problems with complex logic can be overcome by using:

a graphical, semi-formal design notation (state transition diagram, finite state automata), and

a technique to produce an extensible object-oriented structure from the diagrams

Chapter 9 28

Form of a State-Transition Form of a State-Transition DiagramDiagram

state1

state1

transitionconditionaction

annotation

Chapter 9 29

Example: Step 1Example: Step 1

Chapter 9 30

Example: Step 2Example: Step 2

Chapter 9 31

Example: Step 3Example: Step 3

Chapter 9 32

Example: Step 4Example: Step 4

Chapter 9 33

Design RepresentationsDesign Representations

Graphically depict the essential elements of a class and the nature of its relationships with other classes.

Section 9.5

Chapter 9 34

A ClassA Class

name

methods

Data/properties

Chapter 9 35

Representing Inheritance

Chapter 9 36

Representing AggregationRepresenting Aggregation

one-one

one-many

Chapter 9 37

Other Relationships

Association (sharing)

Creation

Chapter 9 38

AnnotationsAnnotations

Chapter 9 39

A Complete ExampleA Complete Example

Chapter 9 40

Design PatternsDesign Patterns

Reuse of design knowledge and experience.

A common practice in many engineering disciplines

Avoids costly rediscovery by novices

Chapter 9 41

Design Patterns

Reuse of design knowledge and experience

Common in many engineering disciplines

Avoids “reinventing the wheel”Gamma, Helm, Johnson, Vlissides,

Design Patterns

Section 9.6

Chapter 9 42

Elements of a Design Elements of a Design PatternPattern

name - simple, descriptive term

intent - brief description of aim

motivation - concrete example

applicability - where is it useful?

structure - “blueprint” diagram

participants - each class in pattern

Chapter 9 43

Elements of a Design Elements of a Design Pattern (cont’d)Pattern (cont’d)

collaborations - relationships among participants

consequences - implications of use

implementation - general implementation

sample code - code for a particular application

known uses - applications where used

related patterns - to combine or substitute

Chapter 9 44

Example Pattern: CompositeExample Pattern: Composite

Structural patternRepresent part-whole relationships

in tree hierarchyUniform treatment of individual

objects

Chapter 9 45

Composite Pattern Example: Graphic

Chapter 9 46

Composite: StructureComposite: Structure

Chapter 9 47

Composite: Application

Part PartType GetType()int GetIdentifier()int GetTime()float GetQuality()int GetNumberOfRejections()SetRejectStatus(bool)bool GetRejectStatus()

CompoundPart AddPart(Part)int GetNumberOfParts()Part * Decompose()

Chapter 9 48

Chain of Responsibility

Behavioral patternPass a request down a chain of

objects Handle a received message Handle a user input event

Request may stop when handled, or continue down to each object in chain

Chapter 9 49

Chain of Responsibility: Structure

Chapter 9 50

Chain of Responsibility: Application

MessageReceiver SetMessageHandler(MessageHandler *)Receive(Message *) MessageHandler * handler

MessageHandler SetSuccessor(MessageHandler *)Handle(Message * message) MessageHandler * successor

StartGameHandler Handle(Message *) Game game

if (msg.GetType() == Start) game.Start()successor->Handle(message)

PlayerPostitionHandler Handle(Message *) Game game

if (msg.GetType() == PlayerMove) { Player player = GetPlayer(message); . . . }successor->Handle(message)

Chapter 9 51

Observer

Behavioral patternWhen changed, Subject notifies

Observers

Chapter 9 52

Observer: Structure

Chapter 9 53

Observer: Sequence Diagram

Chapter 9 54

Observer: Application

Unit AddPart(Part *)GetNumberFinalParts()Part * GetFinalPart()SetTypesRequired(PartType *, int num)AddUnitObserver(UnitObserver *) NotifyObservers()

UnitObserver Update()Update(Unit *)

ProductRemovalObserver Update(Unit *)

Observer Update()

// called when unit completes a partfor all o in observers o.Update(this)