Chapter 9

1. Chapter 9 Object-Oriented Design Chapter 9

2. Topics • Class Design • Class Hierarchy Design • Designing Complex Logic • Design Representations • Design Patterns Chapter 9

3. Class Design: Perspectives Behavioral Information specification Structural Chapter 9

4. Behavioral 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 Classes • actor (does something) • reactor (system events, external events, user events) • agent (messenger, server, finder, communicator) • transformer (formatter, filter) Chapter 9

6. Structual 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 Classes • acquaintance (symmetric, asymmetric) • containment (collaborator, controller) • collection (peer, iterator, coordinator) Chapter 9

8. Information 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 Classes DataState • source/sink • query • result • buffer • cache • synchronizer • recorder • scheduler • maintainer Chapter 9

10. Evaluating a Class Design • Abstraction : does the class capture a useful abstraction • Responsibilities : does the class bear a reasonable set of responsbilities • Interface : is the interface of the class clean and simple • Usage : is the class design consistent with how it is actually used • Implementtion : is there a reasonable implementation for the class Chapter 9

11. Evaluating 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 Responsibilities • 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 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 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 Implementation 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 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 Dimensions Chapter 9

18. “Rationalizing” a Class Hierarchy 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 Hierarchy Chapter 9

20. A Process to Design a Class 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 Example Chapter 9

22. First Iteration Chapter 9

23. Second Iteration Chapter 9

24. Third Iteration Chapter 9

25. Fourth Iteration Chapter 9

26. Designing Complex Logic Section 9.4 • Complex decision-making scenarios are difficult to: • state precisely • understand clearly • program correctly • design for extensibility Chapter 9

27. Designing 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 Diagram annotation state1 transition condition action state1 Chapter 9

29. Example: Step 1 Chapter 9

30. Example: Step 2 Chapter 9

31. Example: Step 3 Chapter 9

32. Example: Step 4 Chapter 9

33. Design Representations Section 9.5 Graphically depict the essential elements of a class and the nature of its relationships with other classes. Chapter 9

34. A Class name Data/properties methods Chapter 9

35. Representing Inheritance Chapter 9

36. Representing Aggregation one-one one-many Chapter 9

37. Other Relationships Association (sharing) Creation Chapter 9

38. Annotations Chapter 9

39. A Complete Example Chapter 9

40. Design Patterns Reuse of design knowledge and experience. A common practice in many engineering disciplines Avoids costly rediscovery by novices Chapter 9

41. Design Patterns Section 9.6 • Reuse of design knowledge and experience • Common in many engineering disciplines • Avoids “reinventing the wheel” • Gamma, Helm, Johnson, Vlissides, Design Patterns Chapter 9

42. Elements of a Design Pattern • 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 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: Composite • Structural pattern • Represent part-whole relationships in tree hierarchy • Uniform treatment of individual objects Chapter 9

45. Composite Pattern Example: Graphic Chapter 9

46. Composite: 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 pattern • Pass 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 PlayerPostitionHandler Handle(Message *) Game game if (msg.GetType() == Start) game.Start() successor->Handle(message) if (msg.GetType() == PlayerMove) { Player player = GetPlayer(message); . . . } successor->Handle(message) Chapter 9