1 / 34

Chapter 17

Chapter 17. GRASP: Designing Objects with Responsibilities. What’s Next. “After identifying your requirements and creating a domain model, add methods to the appropriate classes and define the messaging between the objects to fulfill the requirements.”. The Critical Tool. Not UML

kimi
Télécharger la présentation

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. CS6359 Fall 2011 John Cole

  2. What’s Next • “After identifying your requirements and creating a domain model, add methods to the appropriate classes and define the messaging between the objects to fulfill the requirements.” CS6359 Fall 2011 John Cole

  3. The Critical Tool • Not UML • A mind well educated in design principles CS6359 Fall 2011 John Cole

  4. Object Design • What has been done? Prior activities • How do things relate? • How much design modeling to do, and how? • What is the output? CS6359 Fall 2011 John Cole

  5. “Process” Inputs • Use Cases—the most architecturally significant, high business value • Programming experiments to find show-stopper technical problems • Use case text defines visible behavior that objects must support • Sequence diagrams • Operation contracts CS6359 Fall 2011 John Cole

  6. Activities • Start coding, with test-first development • Start some UML modeling for object design • Or start with another modeling technique such as CRC cards • Models are to understand and communicate, not to document CS6359 Fall 2011 John Cole

  7. Outputs • UML interaction, class, and package diagrams • UI sketches and prototypes • Database models • Report sketches and prototypes CS6359 Fall 2011 John Cole

  8. Responsibilities • Responsibilities, Roles, and Collaboration • Responsibility-driven design • Doing responsibilities • Knowing responsibilities • Low representational gap CS6359 Fall 2011 John Cole

  9. GRASP • General Responsibility Assignment Software Pattern • A learning aid for OO design with responsibilities CS6359 Fall 2011 John Cole

  10. Responsibilities, GRASP, UML • Assign responsibilities to objects while coding or drawing interaction diagrams. • Diagram on p. 278: Sale objects create payments, invoked with a makePayment message. CS6359 Fall 2011 John Cole

  11. Patterns • General principles and idiomatic solutions for creating software • If codified in a format describing the problem and solution, these become patterns • For example: Information Expert • Problem: what is the basic principle by which to assign responsibilities to objects? • Solution: assign to a class that has the information to fulfill it CS6359 Fall 2011 John Cole

  12. Pattern Names • Names give us a way to deal with larger-scale things rather than describing them • Facilitates communication • No “new patterns” Pattern means repetition • GRASP codifies and names existing patterns CS6359 Fall 2011 John Cole

  13. Gang of Four • Initial 23 design patterns. CS6359 Fall 2011 John Cole

  14. GRASP Patterns • Creator • Information Expert • Low Coupling • Controller • High Cohesion CS6359 Fall 2011 John Cole

  15. Creator Pattern • Who creates a particular object? • In Monopoly, who creates the Square object? • Obviously, the Board object. Not the dice, not the chance cards, but the Board. • So, in general, containers create the things contained CS6359 Fall 2011 John Cole

  16. Creator • Problem: Who creates A? • Solution: assign class B the responsibility to create an instance of A if one or more are true: • B contains or aggregates A • B records A • B closely uses A • B has the initializing data for A CS6359 Fall 2011 John Cole

  17. Creator • A composite object is usually a good choice for creating its parts • If a class has the initialization data for an object, this is the Expert pattern CS6359 Fall 2011 John Cole

  18. Creator--Contraindications • When not to use: • When creating requires complexity, such as using existing instances of a class, conditionally creating an instance from one class or another based upon some external property, etc. • In these cases, delegate creation to a helper class called a Concrete Factory or Abstract Factory (p.440) CS6359 Fall 2011 John Cole

  19. Expert • This is the class that has the information necessary to fulfill some responsibility. • If there are relevant classes in the design model, look there first. • If not, look at the domain model CS6359 Fall 2011 John Cole

  20. Expert • For example, in NextGen, some class needs to know the grand total of a sale. Who? • To determine the grand total, we need all SalesLineItem instances. • Sale has these, so it is the logical choice • SalesLineItem can determine the subtotal for each line item, so it is the Expert there • ProductDescription knows the prices CS6359 Fall 2011 John Cole

  21. Expert-- Contraindications • When there are problems with coupling or cohesion • For example, Sale has all the sale data, so you could logically think it would store that in the database. However, that makes Sale dependent upon database (third layer) logic CS6359 Fall 2011 John Cole

  22. Low Coupling • Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies upon other elements • An element with Low Coupling is not dependent upon too many other elements. But how many is too many? • High coupling is not really the problem; it is high coupling to potentially unstable (likely to be changed) objects. CS6359 Fall 2011 John Cole

  23. Low Coupling • Problems with high coupling: • Forced local changes because of changes in related classes • Harder to understand in isolation • Harder to reuse because it requires other classes • Assign responsibility so coupling remains low • This reduces the impact of change CS6359 Fall 2011 John Cole

  24. NextGen example • If we need to create a Payment instance and associate it with Sale, who should do it? Since Register records a payment, the Creator pattern suggests it • On the other hand, Sale could create Payment and that would not increase the coupling • In practice, level of coupling alone is not sufficient CS6359 Fall 2011 John Cole

  25. Forms of Coupling • X has an attribute of type Y • A type X object calls on services in Y • X has a method that references an instance of Y • X is a direct or indirect subclass of Y • Y is an interface that X implements CS6359 Fall 2011 John Cole

  26. Controller • This is an object just below the UI layer that coordinates a system’s operation • For example, the “End Sale” button in a POS system or the “Spell Check” button on a word processor. • This is a delegation pattern CS6359 Fall 2011 John Cole

  27. Controller • Assign responsibility to a class with one of the following: • Represents the overall “system,” a “root object,” a device the software is running within, or a major subsystem (façade controller) • Represents a use case scenario within which the system event occurs, often called <UseCaseName>Handler • Window, View, and Document are not on the list CS6359 Fall 2011 John Cole

  28. Controller • The UI layer gets data and an “Enter Item” message (or some other message, in the case of the assignment) CS6359 Fall 2011 John Cole

  29. Controller • You may want to use the same controller class for all system events of one use case so it can maintain state. • Possible problem of over-assignment of responsibility • It should delegate the work to other objects, not do it CS6359 Fall 2011 John Cole

  30. Façade Controller • Suitable when there are not too many system events • This could be an abstraction of the overall physical unit, such as PhoneSwitch, CashRegister, etc. CS6359 Fall 2011 John Cole

  31. Use Case Controller • When using a façade controller leads to low cohesion and high coupling • When the code in façade controller gets too big CS6359 Fall 2011 John Cole

  32. Bloated Controller • There is only one and it handles too many events • The controller performs the work rather than delegating it • Controller has many attributes and maintains significant system or domain info CS6359 Fall 2011 John Cole

  33. High Cohesion • Cohesion is a measure of how strongly related the responsibilities of an element are • A class with low cohesion does many unrelated things. It is hard to understand, hard to reuse, hard to maintain, and delicate • In the POS system, if Register creates the payment, this is less cohesive than if Sale does it CS6359 Fall 2011 John Cole

  34. High Cohesion • A class with high cohesion has a relatively small number of highly-related methods • It collaborates with other objects • Modular design CS6359 Fall 2011 John Cole

More Related