Connie's Convenience Store - About Peter Coad

34 Connie’s Convenience Store Establishing Responsibilities for Problem-Domain Objects
model (and later, in code), a cashier object is an abstraction; it’s not the real thing; it’s a
figment of your imagination.
A cashier object “knows” and “does” things that the system needs to do, pertaining
to the actual cashier. The cashier object and an actual cashier match up perfectly. The
cashier object’s attributes and the actual cashier’s attributes match up, too.
#50. “Select Attributes from Actual Ones” Strategy establishing responsibilities /
what I know (fundamentals)
• This is an aspect of a software object coming to life: “I know selective things that describe
the actual object that I’m an abstraction of.”
• Select the attributes for your software objects, taken from the abundance of the attributes
that could be used to describe a corresponding actual (real-world) object.
• Consider attributes from a broad-sweeping perspective; then work your way into the
specific ones you need. Look at attributes in general, in this domain, and ultimately just
within this system’s responsibilities.
The cashier object’s services and the actual cashier’s services match up, too—but
only if you are developing a simulation system. Otherwise, and that means for most applications,
the services are remarkably different.
Why? Because the services for an object in an object model are those services that
it must fulfill to do its part in achieving the system’s responsibilities. And the services
that an object in an object model is best suited for are the ones which take advantage of
and fully utilize what that object knows and who that object knows. Then an object
comes to life with what it does.
You want to ask the question “Is authorized?” Which automated object should you
turn to? Or you want to send the command “assess performance for a time interval.”
Who does this work for you?
The worker is a cashier object, of course. It’s the one with sufficient knowledge to
coordinate getting these services accomplished. (Otherwise, without this approach, you
end up with a model of data-holding “objects” and function-blob “objects.” Yuck!)
By letting a cashier object take on these services itself, you get lower coupling,
stronger cohesion, and domain-based partitioning of services (not just domain-based
partitioning of attributes). What a deal!
A side note: personification is a vital aspect of “object think.” It’s one of the most
important principles on where to place a service. It helps object modelers strive for distributed
attributes and services, based upon the domain-based partitioning of classes. It
helps people let go of “DFD think” and “ERD think.” 2 Moreover, personification itself is
extremely engaging. Try it out, especially when working out dynamics with scenarios.
What kind of services do you need for cashier?
2 DFD stands for data flow diagram and ERD stands for entity-relationship diagram. These are
both part of design methods that separate data and functions. Yuck!