Fundamentals (what I do)
Str#86. "Do It Myself" Strategy
- This is an aspect of a software object coming to life: "I
do those things that are normally done to the actual object
that I'm an abstraction of."
- Here's why. "Doing it myself" encapsulates attributes
with the services that work on those attributes. That results
in lower coupling and stronger cohesion.
- If you are building a simulation system, then a software
object will mimic what an actual object does. In most
systems, this is not so. Software objects do those things
that the system is responsible to do with regard to that
object.
Str#87. "Put Services with the Attributes They Work On"
Strategy
- Put the services with the attributes they work on.
- The result? Sensor objects that monitor themselves,
customer objects that qualify themselves, target objects that
destroy themselves.
- Why: better encapsulation, stronger cohesion, lower
coupling, increased likelihood of reuse.
Str#88. "Why, Why, Why" Strategy
- Add value by asking "why, why, why?"
-
- Why, why, does the system need this object
anyway?
- What useful questions can it answer? What useful
actions can it perform?
- What is done to an actual object, something that this
object could do itself?
Str#89. "Basic Services" Strategy
- The basic service, done by all, are not shown in an
object model, except within specific scenario views that
might use them.
- The basics: get, set; add (a connecting object), remove
(a connecting object); create (something a class does) and
initialize, delete.
- Note: attributes are private, by convention. In
scenarios, use "get <attribute name>" and "set
<attribute name>" services to access attribute
values.
- The basic DM services -- for data management objects --
are: search, load, and save.
Str#90. "Service as a Question" Strategy
- Ask: what questions can an object answer?
- Some good starting words to choose from: has
<connecting object>, how many, how much, includes
<connecting object>, is <status value>.
- Why: stronger encapsulation, better partitioning of
services; fewer objects that are mere data holders.
Str#91. "Service as a Verb" Strategy
- Some good service name verbs to choose from:
-
- activate (initialize, initiate, open, start)
- answer (reply, respond)
- assess (appraise, assay, evaluate, value)
- calculate (compute, count, estimate, rate,
tally)
- deactivate (close, end, shut down, terminate)
- determine (decide, figure out, observe, resolve)
- find (get, look for, pinpoint)
- measure (bound, gauge, limit)
- monitor (conduct, direct, manage, observe, operate,
supervise, watch)
- qualify (characterize, differentiate, discriminate,
distinguish, mark)
- select (choose, cull, elect, opt for, pick).
- Append "over interval" for services that apply to
different time intervals.
Str#92. "What Can I Do for You" Strategy
- Ask, "What can I do for you, based on what I know?"
- Ask, "What can I do for you, based on whom I know?"
Str#93. "Question, Calculation, Selection" Strategy
- For an object, consider:
-
- What questions can I answer?
- What calculations can I do? What ongoing monitoring
could I do? What calculations across a collection could I
make (letting each worker do its part)?
- What selections across a collection could I make
(letting each worker do its part)?
Establishing responsibilities
/ what I do
Strategies for building object
models