View
218
Download
3
Category
Preview:
Citation preview
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)
Recommended