17. GRASP—Designing Objects with Responsibilities III CSE5324 Lecture Quiz 17 due at 5 PM Thursday, 8 October 2015

17.10 Creator Pattern Purpose Dynamic creation of objects based upon easily interchangeable algorithms. Use When B “contains” or compositely aggregates A, records A or closely uses A. B has the initializing data for A that will be passed to A when it is created. Thus B is an Expert with respect to creating A. Example In the NextGen POS, we must choose a creator for the :SalesLineItem instance. Sale aggregates the SalesLineItem attribute (Figure 17.12), and the interaction diagram (Figure 17.13) clearly implicates :Sale as its creator. CREATOR Object Creational :Director :Creature :Creator makeItem(quantity) create(quantity)

17.11 (Information) Expert Pattern Purpose Encapsulate a responsibility in a class having the information needed to fulfill it. Use When Intuitively assigning responsibilities to classes. A class has (most of) the expertise needed to complete a task. That class is associated with others can provide any missing information. Example In the NextGen POS, some class needs to know the grand total of a sale. If the initial Design Model has no relevant classes, look in the Domain Model (Figure 17.14), expanding it if necessary. Encouraged by Sale’s associations with all SalesLineItem instances, their quantities and prices, we easily add a getTotal() method to the Design Model’s interaction and class diagrams (Figures ). EXPERTObject Behavioral :Expert :Descriptio n :Item st = getSubtotal() p = getPrice() t = getTotal()

17.12 Low Coupling Principle Purpose Choose the design alternative that minimizes connections among elements. Use When A class has an attribute that is declared in another (unstable) class. A class calls on another (unstable) class’ methods. A class is a direct or indirect subclass of another (unstable) class. Example In the NextGen POS, either :Register (Figure 17.18) or :Sale (Figure 17.19) can create :Payment. Sale must eventually be coupled to the knowledge of Payment, while Register knows relatively little and only during the keyboard entry process. The second alternative is preferred for its reduced coupling. LOW COUPLING Class and Object Stuctural :Agent :Creature :Creator initialize() create()

17.13 (Façade) Controller Pattern Purpose Choose the first object(s) beyond the UI layer (e.g., :Robot) to control all access to it. Each controller delegates all work to downstream Domain Layer applications. Use When A class represents the overall “system” or its “root object.” A class represents a use case scenario containing a single system event; e.g., handler, coordinator, session. (The UI Layer does not handle system events.) Marketing expresses a strong desire for reuse and pluggable interfaces. Example The NextGen POS application contains several system operations; e.g., enterItem(), makeNewSale(), endSale(), makePayment(). Instead of gathering these into a :System class (Figure 17.20), assign a :ProcessSaleHandler class that responsibility (Figure 17.23). CONTROLLERObject Structural :GUI :Controller :JFrame system(event) sysOprn(ID) button() UI Layer Domain Layer delegate()

17.14 High Cohesion Principle Purpose Choose the design alternative that keeps objects focused, understandable and manageable. Use When A class has too many or unrelated responsibilities. Design clarity and comprehension is critical. Example In the NextGen POS, either :Register (Figure 17.26) or :Sale (Figure 17.27) can create :Payment. If :Register also takes the responsibilities of 50 other system operations, it would become a “bloated” incohesive object. The second alternative, in which :Register passively delegates the makePayment() responsibility to :Sale, is preferred for its higher cohesion. HIGH COHESION Class and Object Stuctural :Delegator :Creature :Creator SysOprn() create() SysOprn()

R U O K ? Match each of the following design principles with its purpose below. 1.Creator. __ 2.Expert. __ 3.Low coupling. __ 4.Controller. __ 5.High cohesion. __ a.Choose the design alternative that keeps objects focused, understandable and manageable. b.Encapsulate a responsibility in a class having the information needed to fulfill it. c.Choose the design alternative that minimizes connections among elements. d.Choose the first object(s) beyond the UI layer to control all access to it. e.Dynamic creation of objects based upon easily interchangeable algorithms.

R U O K ? Match each of the following design principles with its indications below. 6. Creator. __ 7. Expert. __ 8. Low coupling. __ 9. Controller. __ 10. High cohesion. __ a.B “contains” or compositely aggregates A, records A or closely uses A. b.A class has taken on too many or unrelated responsibilities. c.A class uses another (unstable) class’ methods or attributes. d.A class has (most of) the expertise needed to complete a task. e.A class represents a use case scenario containing a single system event.

R U O K ? Match each of the following design principles with an example of its use below. 11. Creator. __ 12. Expert. __ 13. Low coupling. __ 14. Controller. __ 15. High cohesion. __ a.Your car’s pilotage and navigation functions are split between two classes. b.Only your car’s :GPS class knows the next turn direction. c.Only the pilot only knows how to stay centered in a traffic lane. d.Your car’s :Controller starts up the GPS’ clock. e.This class handles system operations, which join its User Interface with its Domain Layers’ hardware DLLs.