Next Gen POS Example GRASP again Same Patterns

Next Gen POS Example GRASP again

Same Patterns Different Example!

Apply Creator • Sales. Line. Item

Fig. 17. 12

Fig. 17. 13

Contraindications • When creation is complex: – Using recycled instances – External property values • Then consider a helper class (Factory)

Information Expert • Some class needs to know the grand total for a sale • Information Expert: – Who has the information

Fig. 17. 14

Fig. 17. 15

Fig. 17. 16

Responsibility • Sale – knows sale total • Sales. Line Item – knows line item subtotal • Product Description – knows price

Fig. 17 Calculate sale total

Discussion Information Expert • Common guide to responsibilities • Spreading of information means spreading of responsibilities • Analogy to real world operations

Contraindications • Example: who saves into the DB? • This is not something to spread across classes – Separation of concerns – Cohesion

Low coupling • Create a payment instance and associate it with a sale

Fig. 17. 18 Create Payment

Fig. 17. 19 Alternate Solution

Discussion • Always consider this during all patterns! • Kinds of coupling in Java, C++ or C# – By attribute reference to an instance – By call – A method refers to a type (param, local, etc. ) – Direct or indirect subclass – Implement an interface

Discussion (cont’d) • Reduce impact of later change • Can’t reduce to zero coupling – goes against the central metaphor of object technology!

Contraindications • High coupling to stable elements is ok

Controller • What first element beyond the UI receives and coordinates a system operation?

Fig. 17. 20 System Operations

Fig. 17. 21

Fig. 17. 22 Controller choices

Fig. 17. 23 Allocation of Operations

Discussion • Be careful of over responsibility

Fig. 17. 24 Desirable Coupling

Fig. 17. 25 Less desirable!

Fig. 17. 26 Bad for Cohesion

Fig. 17. 27 Better

GRASP Patterns • Patterns for object design • Still requires judgment