Next Gen POS Example GRASP again

Same Patterns Different Example!

Apply Creator SalesLineItem

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 Who has the information

Fig. 17.14

Fig. 17.15

Fig. 17.16

Responsibility Sale – knows sale total SalesLine Item – knows line item subtotal Product Description – knows price

Fig. 17.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

Reduce impact of later change Can’t reduce to zero coupling!

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.24Desirable Coupling

Fig. 17.25 Less desirable!

Fig. 17.26 Bad for Cohesion

Fig. 17.27 Better

GRASP Patterns Patterns for object design Still requires judgement