14 grasp-1
0 likes1,177 views
This document discusses the GRASP (General Responsibility Assignment Software Patterns) patterns Creator and Information Expert. It provides examples and explanations of when and how to apply these patterns to assign responsibilities in object-oriented design. The Creator pattern assigns the responsibility of creating a new instance of a class to the class that contains or closely uses the new instance. The Information Expert pattern assigns responsibility to the class that has the necessary information to fulfill that responsibility. Partial information experts may collaborate by sharing information through method calls. These patterns aim to achieve low coupling between classes.
![T++ — CISDD — NYSIA GRASP - OOAD
Information Expert — ”Real World” Analogy
? “Do It Myself” [Coad] or “Animation” [Larman] principle — objects are “alive”
and can do things themselves
? “Those who know do”
? Ultimate knowledge may require co-operation
Aron Trauring — Zoteca 16](https://image.slidesharecdn.com/14-grasp-1-130401072643-phpapp02/85/14-grasp-1-17-320.jpg)
![[系列活動] 資料探勘速遊](https://cdn.slidesharecdn.com/ss_thumbnails/0114ycchendmquicktour-170110050658-thumbnail.jpg?width=560&fit=bounds)
More Related Content
Viewers also liked (12)
Similar to 14 grasp-1 (20)
14 grasp-1
- 1. GRASP — General Responsibility Assignment Software Patterns Object Oriented Analysis and Design Aron Trauring T++ Technical Skills Training Program CUNY Institute for Software Design & Development (CISDD) New York Software Industry Association (NYSIA) December 17th, 2004 Aron Trauring — Zoteca
- 2. T++ — CISDD — NYSIA GRASP - OOAD Mini Exercise 1 Who will create Square object in Monopoly? (Use DM Larman p.158) Aron Trauring — Zoteca 1
- 3. T++ — CISDD — NYSIA GRASP - OOAD Solution (Larman p. 283) ? Have no design model so start with Domain Model ? Low representational gap — build design model (dynamic and static) ? He who knows is responsible Aron Trauring — Zoteca 2
- 4. T++ — CISDD — NYSIA GRASP - OOAD Creator Creator 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 of these is true: 1. B “contains” or compositely aggregates A 2. B records A 3. B closely uses A Aron Trauring — Zoteca 3
- 5. T++ — CISDD — NYSIA GRASP - OOAD 4. B has the initializing data for A that will be passed to A when it is created (B is an expert w.r.t. A) If more than one applies, prefer a class B that meets criterion 1. Aron Trauring — Zoteca 4
- 6. T++ — CISDD — NYSIA GRASP - OOAD Creator — Example OrderLine ? Order meets criterion 4 ? Determines method addLineItem() Aron Trauring — Zoteca 5
- 7. T++ — CISDD — NYSIA GRASP - OOAD Creator — When Not to Use ? When want to reuse existing instances for performance purposes (caching) ? Really need instance of subclass base on some external criteria ? Other more complex situations ? Delegate responsibility further down Aron Trauring — Zoteca 6
- 8. T++ — CISDD — NYSIA GRASP - OOAD Creator — Bene?ts ? Existing associations means created class is in any case visible to creator ? High cohesion ? Does not increase coupling Aron Trauring — Zoteca 7
- 9. T++ — CISDD — NYSIA GRASP - OOAD Mini Exercise 2 — Given a key, which object can tell me about ? Square in Monopoly ? LineItem in Example DCD ? Total in same example Aron Trauring — Zoteca 8
- 10. T++ — CISDD — NYSIA GRASP - OOAD Information Expert Information Expert Problem: What is a general principle of assigning responsibility to objects? Solution: Assign responsibility to the class that has the information necessary to ful?ll responsibility Aron Trauring — Zoteca 9
- 11. T++ — CISDD — NYSIA GRASP - OOAD Information Expert — How to? 1. Clearly state the responsibility 2. Look in Design Model for relevant classes 3. Else look in Domain Model and create design classes Aron Trauring — Zoteca 10
- 12. T++ — CISDD — NYSIA GRASP - OOAD Information Expert — Sale Total Example ? Who should know the grand total of a sale? ? Product has information about Price so it is expert for that (getPrice method) ? LineItems has information about Product and Quantity so it is expert for PriceTotal (getPriceTotal method) ? Sale has information LineItems with associated PriceTotal so it is expert for SaleTotal (getSaleTotal method) Aron Trauring — Zoteca 11
- 13. T++ — CISDD — NYSIA GRASP - OOAD Information Expert — Sample UML Model ? getSubTotal == getPriceTotal Aron Trauring — Zoteca 12
- 14. T++ — CISDD — NYSIA GRASP - OOAD ? getTotal == getSaleTotal Aron Trauring — Zoteca 13
- 15. T++ — CISDD — NYSIA GRASP - OOAD Information Expert — Sample Code Model ? Might be simpler to show in code Aron Trauring — Zoteca 14
- 16. T++ — CISDD — NYSIA GRASP - OOAD Partial Information Expert ? Ful?lling responsibility may require information spread across di?erent classes ? Partial information experts collaborate in task — getSaleTotal example ? Interact through messages (methods) to share the work Aron Trauring — Zoteca 15
- 17. T++ — CISDD — NYSIA GRASP - OOAD Information Expert — ”Real World” Analogy ? “Do It Myself” [Coad] or “Animation” [Larman] principle — objects are “alive” and can do things themselves ? “Those who know do” ? Ultimate knowledge may require co-operation Aron Trauring — Zoteca 16
- 18. T++ — CISDD — NYSIA GRASP - OOAD Information Expert — When Not to Use ? When violate low coupling and high cohesion goals ? Product does not look up its price and description directly — Application Logic vs. Technical Services (Database) ? Sale does not save itself in database ? Knowing about Database services would lower cohesion and increase cross-layer coupling ? “Separation of Major Concerns” principle — architectural issue Aron Trauring — Zoteca 17
- 19. T++ — CISDD — NYSIA GRASP - OOAD Information Expert — Bene?ts ? Encapsulation — objects support their own information — supports low coupling ? Behavior is distributed across classes — supports high cohesion Aron Trauring — Zoteca 18
- 20. T++ — CISDD — NYSIA GRASP - OOAD Mini-Exercise 3 Who creates the Payment? ? makePayment method invoked in Register ? A Payment has to be associated with the Sale ? Who creates the Payment instance? Aron Trauring — Zoteca 19
- 21. T++ — CISDD — NYSIA GRASP - OOAD Solution 1 Aron Trauring — Zoteca 20
- 22. T++ — CISDD — NYSIA GRASP - OOAD Solution 1 — Justi?cation ? Register records Payment ? Creator pattern ? addPayment method passes p instance of Payment as parameter ? Register coupled to Payment class Aron Trauring — Zoteca 21
- 23. T++ — CISDD — NYSIA GRASP - OOAD Solution 2 Aron Trauring — Zoteca 22
- 24. T++ — CISDD — NYSIA GRASP - OOAD Coupling Measure of how strongly one element is: 1. connected to 2. has knowledge of 3. relies on another element Aron Trauring — Zoteca 23
- 25. T++ — CISDD — NYSIA GRASP - OOAD Problems with High Coupling ? Forced local changes because of changes in related class ? Harder to understand in isolation ? Harder to reuse — drags in more classes Aron Trauring — Zoteca 24
- 26. T++ — CISDD — NYSIA GRASP - OOAD Low Coupling Low Coupling Problem: How to support low dependency, low change impact and increased reuse? Solution: Assign responsibility so coupling remains low. Use this principle to evaluate alternatives All other things being equal prefer the low coupling solution Note: Information Expert encourages Low Coupling Aron Trauring — Zoteca 25
- 27. T++ — CISDD — NYSIA GRASP - OOAD Types of Coupling ? ClassX has an attribute (data member or instance variable) that refers to ClassY or ClassY instance Sale contains Orderline ? ClassX object calls on services of a ClassY object Product calls ProductCatalog.lookupPrice(itemID) ? ClassX has a method that references ClassY or ClassY instance In Orderline: Aron Trauring — Zoteca 26
- 28. T++ — CISDD — NYSIA GRASP - OOAD def getPriceTotal(self): return (self.product.getPrice() * self.quantity) ? ClassX is a direct or indirect subclass of ClassY Class PizzaBot(Chef) ? ClassX is an interface, and ClassY implements that interface Lamp.Turnon Aron Trauring — Zoteca 27
- 29. T++ — CISDD — NYSIA GRASP - OOAD Low Coupling — Observations ? Evaluative principle — needs to be considered in context of other principles ? Measure current degree of coupling and assess “damage” of increasing ? Example: Tradeo?s between bene?ts of sub-classing and increased coupling ? Generic classes with high probability of reuse should have low coupling ? Try not be highly coupled to unstable parts of system if can Aron Trauring — Zoteca 28
- 30. T++ — CISDD — NYSIA GRASP - OOAD Low Coupling — When Not To ? Too little coupling means we aren’t a “collaborating community of objects” ? It’s ok to be highly coupled with stable or pervasive elements (e.g. language libraries) Aron Trauring — Zoteca 29
- 31. T++ — CISDD — NYSIA GRASP - OOAD Low Coupling — Bene?ts ? Not a?ected by changes in other components ? Simple to understand in isolation ? Convenient to reuse Aron Trauring — Zoteca 30
- 32. T++ — CISDD — NYSIA GRASP - OOAD Controller — Understanding the Problem ? SSD — boundary between the User and SUD ? UI layer “catches” the request ? The request is a system operation — public interface ? Model-View Separation principle says UI must not contain business logic ? Problem: to which domain layer object should the UI pass the system operation? Aron Trauring — Zoteca 31
- 33. T++ — CISDD — NYSIA GRASP - OOAD Mini Exercise 1 — Lahrman p. 288 — Which object starts the game? Aron Trauring — Zoteca 32
- 34. T++ — CISDD — NYSIA GRASP - OOAD Controller Controller Problem: What ?rst object beyond the UI layer receives and co-ordinates (controls) a system operation Solution: Assign the responsibility to a class representing one of the following choices: 1. Facade Controller : represents the overall system, a root object, a device that the object is running within, or a major sub-system 2. Use Case or Session Controller : represents a use case scenario within which the system event occurs Aron Trauring — Zoteca 33
- 35. T++ — CISDD — NYSIA GRASP - OOAD Session Controllers ? Naming conventions: <UseCaseName>Handler or <UseCaseName>CoOrdinator or <UseCaseName>Session ? Use same controller class for all system operations in the use case scenario ? Session is a type of conversation between the actor and the SUD Aron Trauring — Zoteca 34
- 36. T++ — CISDD — NYSIA GRASP - OOAD Mini Exercise 1 — Solution on pp. 288-9 Aron Trauring — Zoteca 35
- 37. T++ — CISDD — NYSIA GRASP - OOAD Controller — NextGen POS Example ? Conceptual representation — what is the the class that handles these opera- tions? Aron Trauring — Zoteca 36
- 38. T++ — CISDD — NYSIA GRASP - OOAD Aron Trauring — Zoteca 37
- 39. T++ — CISDD — NYSIA GRASP - OOAD Controller Example — Options ? Facade: Register, POSSystem ? Session: ProcessSaleHandler, ProcessSaleSession ? Aron Trauring — Zoteca 38
- 40. T++ — CISDD — NYSIA GRASP - OOAD Aron Trauring — Zoteca 39 ?
- 41. T++ — CISDD — NYSIA GRASP - OOAD Controller — Observations ? Delegation pattern ? External input events may come from human actors or other systems ? Facade — the “face” of the domain layer to the world Ex: Register ? Handler — deals with a clear cut part of the issue Ex: ProcessSale ? Session — conversation where information needs to be retained between steps Aron Trauring — Zoteca 40
- 42. T++ — CISDD — NYSIA GRASP - OOAD Ex: identify out of sequence EndSale before MakePayment Aron Trauring — Zoteca 41
- 43. T++ — CISDD — NYSIA GRASP - OOAD Controller — Facade ? “cover” over the other layers of the application ? Abstraction of an overall physical unit — Register, PizzaShop ? The entire software system — POSSystem ? Abstraction of some other overall system or sub-system concept — MonopolyGame ? Suitable for relatively small systems and/or system with limited number of system operations ? Suitable in message handling system when can’t direct messages to alternative controllers — Internet application servers Aron Trauring — Zoteca 42
- 44. T++ — CISDD — NYSIA GRASP - OOAD Controller — Use Case ? Pure Fabrication — ProcessSaleHandler in not a domain concept in Domain Model ? When assigning to facade may lead to high coupling or low cohesion (“Bloat”) ? Many system operations across di?erent processes ? Conceptually easier to understand and build Aron Trauring — Zoteca 43
- 45. T++ — CISDD — NYSIA GRASP - OOAD Controller vs. UI ? UI should not have responsibility for ful?lling system operations ? System operations handled in domain layer ? Controller is responsible for forwarding messages on Aron Trauring — Zoteca 44
- 46. T++ — CISDD — NYSIA GRASP - OOAD Controller — Bene?ts ? Allows for easy change of UI and/or alternative UI and/or Batch mode ? Allows for reuse of domain layer code (UI is usually application speci?c) ? Helps ensure sequence of operation which may di?er from UI input ? Can reason about system state — UI does not preserve state Aron Trauring — Zoteca 45
- 47. T++ — CISDD — NYSIA GRASP - OOAD Bloated Controllers — The Problem ? Low cohesion — unfocused and handling too many areas of responsibility: ? When have a facade controller handling all of many system events ? When the controller performs many of the system operations instead of delegating ? When the controller has many attributes (much information) about the system which should be distributed to or duplicates from elsewhere Aron Trauring — Zoteca 46
- 48. T++ — CISDD — NYSIA GRASP - OOAD Bloated Controllers — The Solution ? Add more controllers — use case instead of facade ? Design the controller so that it delegates operations to other objects ? High Cohesion is itself a GRASP principle Aron Trauring — Zoteca 47
- 49. T++ — CISDD — NYSIA GRASP - OOAD Bloated Controllers — POS Example ? ProcessSalesHandler ? ProcessReturnsHandler ? ProcessPaymentHandler Aron Trauring — Zoteca 48
- 50. T++ — CISDD — NYSIA GRASP - OOAD Cohesion De?ned ? measure of how strongly related and focused the responsibilities of an object are ? Goal: highly related responsibilities ? Goal: small number of responsibilities Aron Trauring — Zoteca 49
- 51. T++ — CISDD — NYSIA GRASP - OOAD Low Cohesion — The Problem ? Hard to understand ? Hard to rescue ? Hard to maintain ? Subject to constant need to change (usually high coupling) Aron Trauring — Zoteca 50
- 52. T++ — CISDD — NYSIA GRASP - OOAD High Cohesion High Cohesion Problem: How to keep objects focused, understandable and manageable, and as a side e?ect support Low Coupling? Solution: Assign responsibility so cohesion remains high. Dosage: Use as an evaluation tool Aron Trauring — Zoteca 51
- 53. T++ — CISDD — NYSIA GRASP - OOAD High Cohesion — NextGen POS Example ? Register creates Payment in real world, so by Creator should in software too ? Danger: Register might start taking on too many responsibilities ? One step in isolation might not be a problem but adding up will lead to low cohesion Aron Trauring — Zoteca 52
- 54. T++ — CISDD — NYSIA GRASP - OOAD ? Delegating to Sale creates greater cohesion in Register ? Second example also has lower coupling, so therefore more desirable on that score Aron Trauring — Zoteca 53
- 55. T++ — CISDD — NYSIA GRASP - OOAD High Cohesion — Observations ? Real world analogy: Delegate responsibility ? Highly related to low coupling ? Needs to be used in conjunction with other principles Aron Trauring — Zoteca 54
- 56. T++ — CISDD — NYSIA GRASP - OOAD High Cohesion — When Not to ? Class that needs to be maintained by a specialist — group functions by area of expertise (SQL queries) ? Performance issues demand grouping a set of operations together — RPC Aron Trauring — Zoteca 55
- 57. T++ — CISDD — NYSIA GRASP - OOAD High Cohesion — Bene?ts ? Clarity and ease of comprehension of design increased ? Maintenance and enhancements are simpli?ed ? Low coupling is often supported ? Enhances reuse Aron Trauring — Zoteca 56