Presentation on GRASP Patterns Submitted by WWW.ASSIGNMENTPOINT.COM

1. Presentation on GRASP PatternsSubmitted byWWW.ASSIGNMENTPOINT.COM www.assignmentpoint.com

2. Patterns • A pattern describes a problemand solution, and given a name. • Examples are Singleton, Adapter, Factory etc. • A pattern Example • Name: Information Expert • Context/Problem: What is a basic principle by which to assign responsibilities to objects? • Solution: Assign a responsibility to the class that has the information needed to fulfill it. www.assignmentpoint.com

3. Repeating Patterns • The very term Pattern means a repeating thing. • The point of pattern is not to express new design ideas • Instead patterns codify existing tried-and-true knowledge, idioms, and principles: the more honed and widely use, the better. www.assignmentpoint.com

4. Naming Patterns Improves Communication • Engineers can discuss among themselves a complex principle or design idea with a simple name. Fred: “Where do you think we should place the responsibility for creating a SalesLineItem? I think a Factory.” Wilma: “By Creator, I think Sale will be suitable.” Fred: “Oh, right – I agree”. www.assignmentpoint.com

5. GRASP Patterns • Question: What is GRASP patters? • Answer: They describe fundamental principles of object design and responsibility assignment, expressed as patterns. • GRASP stands for General Responsibility Assignment Software Patterns. • Information Expert • Creator • High Cohesion • Low Coupling • Controller www.assignmentpoint.com

6. 1. Information Expert (or Expert) • Context/Problem: What is a basic principle by which to assign responsibilities to objects? • Solution: Assign a responsibility to the class that has the information needed to fulfill it. • Example: In NextGen POS application, some class needs to know the grand total of a sale. • Start by asking “Who should be responsible for knowing the grand total of a sale?” • By Information Expert we should look for a class that has the information needed to determine the total. • Where should we look, domain or design model? • First look into design model, if not then look into domain model www.assignmentpoint.com

7. Domain Model vs. Design Model Let’s assume we are starting from domain model www.assignmentpoint.com

8. NextGen POS System Domain Model Who has the information to determine the sales total? www.assignmentpoint.com

9. Add Responsibilities • So we add a software class into design model similarly called Sale, and give the responsibility of knowing its total, expressed with the method named getTotal (). • A responsibility is not the same thing as a method, but methods are implemented to fulfill responsibilities. • Responsibilities are implemented using methods that either act alone or collaborate with other methods and objects www.assignmentpoint.com

10. Types of Responsibility • Two types of responsibilities, knowing and doing. • Knowing responsibilities of an object include: • Knowing about private encapsulated data • Knowing about related objects • Knowing about things it can derive or calculate • E.g. Sale object is responsible for knowing its total. • Doing responsibilities of an object include: • Doing something itself e.g. creating object or doing a calculation • Initiating action in other objects • Controlling and coordinating activities in other objects • E.g. a Sale is responsible for creating SalesLineItems” (a doing) www.assignmentpoint.com

11. Associations of Sale www.assignmentpoint.com

12. Determining Sales Total • Determining sales total needs SalesLineItem.quantity and ProductSpecification.price. • By Information Expert SalesLineItem should determine the subtotal. • Thus Sale should send getSubtotal messages to each of SalesLineItems and sum the results. www.assignmentpoint.com

13. Determining Sales Total • ProductSpecification is an information expert on answering its price; • Therefore, a message must be sent to it asking for its price. www.assignmentpoint.com

14. Implementation Classes Class ProductSpecification String desription; float price ; int itemID void setItemID (int itemID) { this.itemID = itemID ; } int getItemID () { return this.itemID ; } void setPrice (float price) float getPrice () void setDescription (String desc) String getDescription () End Class Class SalesLineItem ProductSpecification ps ; int quantity ; void setProductSpecification (…) Pro..Spec.. getProductSpecification () void setQuantity (int qty) int getPrice () void setDescription (String desc) String getDescription () float getSubtotal (){ return quantity * ps.getPrice () } End Class www.assignmentpoint.com

15. Class Sale LinkedList <SalesLineitem> sliList; Date date ; Time time ; float getTotal (){ float total = 0 ; for each item in sliList total = total + item.getSubTotal () end For return total ; } End Class Class SalesLineItem ProductSpecification ps ; int quantity ; void setProductSpecification (…) Pro..Spec.. getProductSpecification () void setQuantity (int qty) int getPrice () void setDescription (String desc) String getDescription () float getSubtotal (){ return quantity * ps.getPrice () } End Class www.assignmentpoint.com

16. Contradictions • Sometimes a solutions suggested by Information Expert is undesirable, usually because of problems in coupling and cohesion. • Who should be responsible for saving a Sale in a database? • Certainly Sale object contains much of the information so Sale object is the natural choice. • But then Sale class mush have codes related to SQL, JDBC etc. • Related Patterns • Low Coupling • High Cohesion www.assignmentpoint.com

17. GRASP Patterns • Information Expert • Creator • Low Coupling • High Cohesion • Controller www.assignmentpoint.com

18. 2. Creator • Context/Problem: Who should be responsible for creating a new instance of some class? • Solution: Assign class B the responsibility to create a class A, if: • B aggregates A objects • B contains A • B records instances of A • B closely uses A • B has the initializing data that will be passed to A when it is created • Example: In NextGen POS application, who should be responsible for creating a SalesLineItem instance? www.assignmentpoint.com

19. Creating a SalesLineItem www.assignmentpoint.com

20. Finding Creator Class • Sometimes a creator is found by looking for the class that has the initializing data that will be passed in during creation. • Example: A Payment instance needs to be initialized, when created, with the Sale total. • A Payment object will create Sale object or • A Sale object will create Payment object • Since Sale knows the total, Sale is a candidate creator for Payment www.assignmentpoint.com

21. Contradictions • Often creation requires significant complexity such as conditional creation based on external property, using recycled instances for performance reason etc. • Delegate creation to a helper class called a Factory rather than suggested by Creator. • Related Patterns • Low coupling • Factory www.assignmentpoint.com

22. GRASP Patterns • Information Expert • Creator • Low Coupling • High Cohesion • Controller www.assignmentpoint.com

23. 3. Low Coupling • Context/Problem: How to support low dependency, low change of cost and increased reuse? • Solution: Assign a responsibility so that coupling remains low • Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements. • Low coupling means not dependent on too many elements e.g. classes, subsystems etc. • High Coupling has the following problem • Changes in related classes force local changes • Harder to understand in isolation • Harder to reuse because its use requires other classes on which it is dependent. www.assignmentpoint.com

24. Low Coupling Example • Consider the following partial class diagram form POS study • Assume we need to create a Payment instance and associate with Sale. • What Class should be responsible for this? • Creator pattern suggests Register as a candidate because Register “records” a Payment. UML notation www.assignmentpoint.com Design 1 Register class is coupled with Payment class

25. Low Coupling Example • Alternatively create Payment and associate with the Sale class • Which design is best? • In any case Sale must eventually be coupled to knowledge of a Payment. So design 2 is better. www.assignmentpoint.com

26. Suggestions • In practice, the level of coupling alone can't be considered in isolation from other principles such as Information Expert and High Cohesion. Nevertheless, it is one factor to consider in improving design. • There is no absolute measure of when coupling is too high. It depends on developer’s design skill. • Even extremely low coupling is not desirable. • OO systems means “a system of connected objects that communicate via messages.” • Extreme low/zero coupling means single object with lot of responsibilities that is in-cohesive, bloated and complex. • Moderate degree of coupling is normal and necessary in OOA/D www.assignmentpoint.com

27. Contradictions • High coupling to stable elements and to pervasive elements is seldom a problem. • For example, J2EE application can safely couple to the Java libraries, because they are stable and widespread. • Pick your battles • It is not high coupling per se that is the problem; it is high coupling to elements that are unstable in some dimension such as their interface, implementation, or mere presence. www.assignmentpoint.com

28. Pick the Battles • Pick the battles between lowering coupling and encapsulating things. • Focus on points of realistic high instability or evolution • Example: In NextGen project, different third-party tax calculators (with unique interface) need to be connected to the system. • Therefore designing for Low Coupling at this point is practical. • Benefits • Not affected by change in other components • Simple to understand in isolation • Convenient to reuse. • Related patters • Protected Variation www.assignmentpoint.com

29. GRASP Patterns • Information Expert • Creator • Low Coupling • High Cohesion • Controller www.assignmentpoint.com

30. 4. High Cohesion • Context/Problem: How to keep complexity manageable? • Solution: Assign a responsibility so that cohesion remains high. • Cohesion: In object design cohesion is a measure of how strongly related and focused the responsibilities or an element are. • Object with high cohesion does not do a tremendous amount of work. • Low cohesion does many unrelated things. www.assignmentpoint.com

31. High Cohesion Example • In this case probably its ok because there are only three classes. • But if there are fifty system operations, all received by Register, then it would become bloated in-cohesive object. www.assignmentpoint.com

32. High Cohesion Example • This Register class is highly cohesive. www.assignmentpoint.com

33. Cohesion and Coupling, Yin and Yang • Bad cohesion usually begets bad coupling, and vice versa • They have inter-dependant influence, thus the term “yin and yang of software engineering”. • Example: consider a GUI widget class that represents and paints a widget, saves data to a database, and invokes remote object services. • It is not only profoundly in-cohesive, but it is coupled to many disparate elements. www.assignmentpoint.com

34. GRASP Patterns • Information Expert • Creator • Low Coupling • High Cohesion • Controller www.assignmentpoint.com

35. 5. Controller • Context/Problem: Who should be responsible for handling an input system event? • Solution: Assign system handling responsibility to a class if: • Represents the overall system, device or sub-system (façade controller) • Represents a use case scenario within which the system event occurs, often named <UseCaseName>Handler, <UseCaseName>Coordinator, <UseCaseName>Sesssion www.assignmentpoint.com

36. Controller Example www.assignmentpoint.com

37. Choice of Controllers • A controller is a non-user interface object responsible for receiving or handling a system event. • First category of controller is a façade controller representing the overall system, device or a subsystem. • Suitable when there are not too-many system events. • Second category is a use-case controller, when there should be many controllers Façade Controller Use-case Controller www.assignmentpoint.com

38. Allocation of System Operations Façade Controller Use-case Controllers www.assignmentpoint.com

39. Desirable Coupling between Interface Layer and Domain Layer www.assignmentpoint.com

40. Less Desirable Coupling between Interface Layer and Domain Layer www.assignmentpoint.com