Next Gen POS Example

GRASP again

Same PatternsDifferent Example!

Apply Creator

• SalesLineItem

Fig. 17.12

Sale

time

SalesLineItem

quantity

ProductDescription

descriptionpriceitemID

Described-by*

Contains

1..*

1

1

Fig. 17.13

: Register : Sale

makeLineItem(quantity)

: SalesLineItemcreate(quantity)

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

Sale

time

SalesLineItem

quantity

ProductDescription

descriptionpriceitemID

Described-by*

Contains

1..*

1

1

Fig. 17.15

Sale

time...

getTotal()

:Salet = getTotal

New method

Fig. 17.16

Sale

time...

getTotal()

SalesLineItem

quantity

getSubtotal()New method

1 *: st = getSubtotal: Salet = getTotal lineItems[ i ] : SalesLineItem

this notation will imply we are iterating over all elements of a collection

Responsibility

• Sale – knows sale total

• SalesLine Item – knows line item subtotal

• Product Description – knows price

Fig. 17.17 Calculate sale total

Sale

time...

getTotal()

SalesLineItem

quantity

getSubtotal()

ProductDescription

descriptionpriceitemID

getPrice()New method

:ProductDescription

1.1: p := getPrice()

1 *: st = getSubtotal: Salet = getTotal lineItems[ i ] :SalesLineItem

DiscussionInformation 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

: Register p : Payment

:Sale

makePayment() 1: create()

2: addPayment(p)

Fig. 17.19 Alternate Solution

: Register :Sale

:Payment

makePayment() 1: makePayment()

1.1. create()

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

System

endSale()enterItem()makeNewSale()makePayment(). . .

Fig. 17.21

Which class of object should be responsible for receiving this system event message?

It is sometimes called the controller or coordinator. It does not normally do the work, but delegates it to other objects.

The controller is a kind of "facade" onto the domain layer from the interface layer.

actionPerformed( actionEvent )

: ???

: Cashier

:SaleJFrame

presses button

enterItem(itemID, qty)

UI Layer

Domain Layer

system operation message

Fig. 17.22 Controller choices

:RegisterenterItem(id, quantity)

:ProcessSaleHandlerenterItem(id, quantity)

Fig. 17.23 Allocation of Operations

Register

...

endSale()enterItem()makeNewSale()makePayment()

makeNewReturn()enterReturnItem(). . .

System

endSale()enterItem()makeNewSale()makePayment()

makeNewReturn()enterReturnItem(). . .

system operations discovered during system behavior analysis

allocation of system operations during design, using one facade controller

ProcessSaleHandler

...

endSale()enterItem()makeNewSale()makePayment()

System

endSale()enterItem()makeNewSale()makePayment()

enterReturnItem()makeNewReturn(). . .

allocation of system operations during design, using several use case controllers

HandleReturnsHandler

...

enterReturnItem()makeNewReturn(). . .

Discussion

• Be careful of over responsibility

actionPerformed( actionEvent )

:Register

: Cashier

:SaleJFrame

presses button

1: enterItem(itemID, qty)

:Sale1.1: makeLineItem(itemID, qty)

UI Layer

Domain Layer

system operation message

controller

Fig. 17.24Desirable Coupling

Fig. 17.25 Less desirable!

Cashier

:SaleJFrame

actionPerformed( actionEvent )

:Sale1: makeLineItem(itemID, qty)

UI Layer

Domain Layer

It is undesirable for an interfacelayer object such as a window to get involved in deciding how to handle domain processes.

Business logic is embedded in the presentation layer, which is not useful.

SaleJFrame should not send this message.

presses button

Fig. 17.26 Bad for Cohesion

: Register : Sale

addPayment( p )

p : Paymentcreate()makePayment()

Fig. 17.27 Better

: Register : Sale

makePayment()

: Paymentcreate()

makePayment()

GRASP Patterns

• Patterns for object design

• Still requires judgment