Date post: | 02-Jan-2016 |
Category: |
Documents |
Upload: | nathan-poole |
View: | 215 times |
Download: | 2 times |
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