Connie's Convenience Store - About Peter Coad
Connie's Convenience Store - About Peter Coad
Connie's Convenience Store - About Peter Coad
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
56 Connie’s <strong>Convenience</strong> <strong>Store</strong> Applying Patterns: Establish Problem-Domain Responsibilities<br />
Collection-worker<br />
Consider the fundamental pattern of object modeling: collection-worker.<br />
#1. “Collection-Worker” Pattern the fundamental pattern<br />
• Collection-worker is the fundamental object-model pattern.<br />
• All other object-model patterns are variations on this theme.<br />
• Typical object interactions<br />
howMany —> calcForMe calcOverWorkers —>calcForMe<br />
howMuch —> calcForMe rankWorkers —>rateMe<br />
• Other notes<br />
“aboutMe” helps one think about what other attributes might be needed<br />
“calcForMe” helps one think about what specific calculations might be needed<br />
“rankMe” helps one think about what ordering or comparrison services might be<br />
“rateMe” helps one think about what self-assessment services might be needed<br />
A collection object knows about some number of workers.<br />
A collection object only does those things which apply across its collection of<br />
workers, e.g., it calculates, rates, and selects.<br />
A worker does all that it can do with what it knows, or with what others may tell it<br />
in combination with what it knows.<br />
How do you find places to apply a pattern? Just look for potential pattern players!<br />
In this case, look for objects that know some number of objects. Such a “knowing”<br />
is indicated with an object connection (or a special kind of object connection, a wholepart<br />
connection) that has an upper-bound constraint of “many.”<br />
Many patterns are collection-worker patterns. Apply some here.<br />
Participant-transaction<br />
number<br />
name<br />
date<br />
time<br />
status<br />
aboutMe<br />
Collection<br />
howMany<br />
howMuch<br />
rankWorkers<br />
calcOverWorkers<br />
calcForMe<br />
n 1<br />
number<br />
name<br />
aboutMe<br />
Worker<br />
calcForMe<br />
rateMe<br />
Okay, you worked with this one a bit earlier. Consider cashier and session. A cashier<br />
object knows all of the sessions it has participated in. So a cashier object is the logical<br />
place to put any service that needs to do something across such a collection of sessions.<br />
For example, you could ask a cashier object to calculate the quantity sold over a specified<br />
interval. You could also let a cashier object calculate its total amount of sales made<br />
over a specified interval. Hence: