1 / 49

Chapter 17

Chapter 17. GRASP: Designing Objects with Responsibilities. Object Design. The purpose of UML drawing is to understand and communicate , not to document. Inputs: use case text, system sequence diagrams, operation contracts, Supplementary Specification, Glossary, Domain Model

virginia-vin
Download Presentation

Chapter 17

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Chapter 17 GRASP: Designing Objects with Responsibilities

  2. Object Design • The purpose of UML drawing is to understand and communicate, not to document. • Inputs: use case text, system sequence diagrams, operation contracts, Supplementary Specification, Glossary, Domain Model • Outputs: UML interaction, class, and package diagrams; UI and report sketches and prototypes; database models

  3. Fig. 17.1 UP artifacts influencing OO design

  4. Responsibility-Driven Design (RDD) • A metaphor for OO software design: a community of collaborating responsible objects. • Responsibility: “a contract or obligation of a classifier” • Doing: • creating an object, doing a calculation, initiating action in other objects, controlling and coordinating • Knowing: • about private encapsulated data, related objects

  5. Fig. 17.2 Responsibilities and methods

  6. Patterns • Patterns: general principles and idiomatic solutions to commonly recurring problems. • Christopher Alexander’s architectural patterns • Kent Beck and Ward Cunningham – software • Gang of Four (GoF) Design Patterns (1994) • A nameddescription of a well-known problem/solution pair. • How to apply it in varying circumstances • Trade-offs, implementations, variations

  7. General Responsibility Assignment Software Patterns • GRASP: nine basic OO design principles or basic building blocks in design. • We start with five patterns, applied to both the POS and Monopoly case studies: • Creator • Information Expert • Low Coupling • Controller • High Cohesion

  8. Creator Pattern • Problem: Who should be responsible for creating a new instance of some class? • Solution: Assign class B the responsibility to create an instance of class A if one or more of these is true: • B contains (compositely aggregates) A. • B records A. • B closely uses A. • B has the initializing data for A that will be passed to A when it is created.

  9. Fig. 17.3 Monopoly iteration-1 domain model

  10. Fig. 17.4 Applying the Creator pattern (dynamic model)

  11. Fig. 17.5 Applying Creator in a static model • Board has a composite aggregation association with Square.

  12. Fig. 17.12 Partial POS domain model

  13. Fig. 17.13 Creating a SalesLineItem

  14. Creator Pattern, continued • Example – as above • Discussion – see textbook (p. 293) • Contraindications: If creation requires significant complexity, delegate to a helper class – a Concrete Factory or Abstract Factory (GoF, see p. 440). • Benefits: Low coupling, because created class is already visible to creator class. • Related patterns or principles – see p. 294

  15. Information Expert (or Expert) Pattern • Problem: What is a general principle of assigning responsibilities to objects? • Solution: Assign a responsibility to the class that has the information needed to fulfill the responsibility. • Example: • In Monopoly, which class should be responsible for knowing a Square, given a key (e.g., its name)?

  16. Fig. 17.6 Applying Expert in Monopoly

  17. Applying Expert in POS Application • Start assigning responsibilities by clearly stating the responsibility. Who should be responsible for knowing the grand total of a sale? • Where do we look for the classes that have the information needed? • First, in the Design Model. • If no relevant classes there, look in the Domain Model, and add a corresponding software class to the Design Model.

  18. Fig. 17.14 Associations of Sale in Domain Model

  19. Fig. 17.15 Partial interaction and class diagrams • Adding a Sale class to the Design Model supports low representational gap. • Express responsibility of knowing the total of a sale with the method named getTotal. What information do we need to know to determine the line item subtotal?

  20. Fig. 17.16 SalesLineItem is Expert for Subtotal How does the SalesLineItem find out the product price? • “Partial” information experts collaborate to fulfill the responsibility.

  21. Fig. 17.17 ProductDescription is Expert for Price

  22. Information Expert, continued • Discussion: The Information Expert pattern often uses Coad’s “Do It Myself” strategy – a software object does those operations that are normally done to the inanimate real-world thing it represents. • Contraindications: The separation of major concerns may suggest a different solution. • E.g., don’t make Sale responsible for saving a sale in a database.

  23. The Low Coupling Principle • Problem: Reduce the impact of change. • Solution: Assign responsibilities so that coupling remains low. • Use this principle to evaluate alternatives. • Coupling: how strongly one element is connected to, has knowledge of, or relies on other elements. • Low coupling tends to reduce the time, effort, and defects in modifying software. • Coupling per se is not a problem, only coupling to elements that are unstable (likely to change).

  24. Fig. 17.7 Don’t assign getSquare to an arbitrary class

  25. Low Coupling in POS Case Study • What class should be responsible for creating a Payment instance and associating it with the Sale? • Register? • Sale? • Creator pattern suggests Register should create the Payment. • A register records a payment in the real world.

  26. Fig. 17.18 Register creates Payment • Register is coupled to both Sale and Payment.

  27. Fig. 17.19 Sale creates Payment • Assuming that the Sale must eventually be coupled to knowledge of a Payment, having Sale create the Payment does not increase coupling. • Low Coupling and Creator suggest different solutions.

  28. Common Forms of Coupling in OO Languages • Type X has an attribute (data member, instance variable) that refers to type Y or an instance of Y. • An object of type X calls on services of a type Y object. • Type X has a method that references an instance of type Y (e.g., parameter, local variable, object returned from a method). • Type X is a subclass of type Y. • Type X implements the interface Y.

  29. Controller Pattern • Problem: What first object beyond the UI layer receives and coordinates (“controls”) a system operation? • Solution: Assign the responsibility to a class that represents • the overall system, a “root” object, a device that the software is running within, or a major subsystem (a façade controller), or • a use case scenario within which the system event occurs (use case or session controller).

  30. Fig. 17.8 System Sequence Diagram for Monopoly

  31. Fig. 17.9 Who is Controller for playGame?

  32. Options for Control Responsibility • Option 1a: Represents the overall system or a root object. • E.g., an object called MonopolyGame. • Option 1b: Represents the device the software is running within. • E.g., Phone or BankCashMachine. • Not applicable in the Monopoly case. • Option 2: Represents the use case or session. • E.g., PlayMonopolyGameHandler.

  33. Fig. 17.10 Using MonopolyGame as Controller • Option 1 is reasonable if there are only a few system operations.

  34. Fig. 17.20 System Operations of POS Application • During analysis, system operations may be assigned to a System class. • Does not mean a software class named System fulfills the system operations during design. • During design, a controller class is assigned the responsibility for system operations.

  35. Fig. 17.21 What should be Controller for enterItem?

  36. Fig. 17.22 Controller Options • In the POS domain, Register is a specialized device with software running on it. • ProcessSaleHandler represents a receiver of all system events of a use case scenario.

  37. Fig. 17.23 Allocation of system operations

  38. Delegation • UI layer objects delegate system events to another layer. • UI layer shouldn’t contain application logic. • Increases potential for reuse. • Can “unplug” UI layer – use a different framework or run in offline “batch” mode. • Controller should delegate the work that needs to be done to other objects. • It controls or coordinates the activity.

  39. Fig. 17.24 Desirable coupling of UI and domain layers

  40. Fig. 17.25 Undesirable coupling of UI to domain layer

  41. Façade Controller • Façade controller represents the overall system, device, or subsystem. • A façade or cover over other layers. • Abstraction of overall physical unit e.g., Register, TelecommSwitch, Robot, or class representing entire system or concept e.g., POSSystem, ChessGame. • Suitable when there are not too many system events or when UI cannot choose between multiple controllers.

  42. Use Case Controller • A use case controller handles system events for a single use case. • Can maintain information about the state of the use case. • E.g., detect out-of-sequence system events. • Different controller for each use case. • Not a domain object, but artificial construct (“pure fabrication”) to support the system. • Use when there are many system events. • Factors handling into separate classes.

  43. Bloated Controllers • Signs of poor controller class design: • A single controller class receives all system events, and there are many of them. • The controller performs many of the tasks of the system operation, without delegating. • The controller has many attributes and maintains significant information about the system or domain that should have been distributed to other objects, or duplicates information found elsewhere.

  44. The High Cohesion Principle • Problem: How to keep objects focused, understandable, and manageable. • Solution: Assign a responsibility so that cohesion remains high. • Use this to evaluate alternatives. • Cohesion: A measure of how strongly related and focused the responsibilities of an element are. • Class with low cohesion does many unrelated things or does too much work.

  45. Fig. 17.11 Contrasting Cohesion in Different Designs

  46. Fig. 17.26 Reduced cohesion of Register

  47. Fig. 17.27 Higher Cohesion and Lower Coupling

  48. Modular Design • Modularity: The property of a system that has been decomposed into a set of cohesive and loosely coupled modules. • Design each method with a clear, single purpose. • Group a related set of concerns into a class.

  49. High Cohesion, continued • Contraindications: Accepting lower cohesion may be justified • To group into one class or component all the code that will be maintained by one person. • E.g., all SQL statements in one class, to be worked on by one or two SQL experts. • When using distributed server objects. • The overhead of remote communication may make it desirable to have fewer, larger, and less cohesive server objects. • See Coarse-Grained Remote Interface.

More Related