Re: Internal State vs. Navigating Associations

Matt,

Very good learning point. I am sure you are on the right track here.
1. Tell (dont ask) bar to do something to itself.
What it should do is the more important and difficult question. If you
cant give it a life in your system, you might consider skipping the
bar object from the system. You might consider asking the questiions
like: "what would we do with a bar ? " to discover potential
behaviors.

2. Conditionals on internal states for the most part are a good reason
to make use of polymorphy. I would also be tempted to further analyse
the state you describe. What is this state good for ? Does bar really
need to keep track of it ?

3. If you want an object to know about something which is more
naturally allocated to another object's internal knowledge we have a
problem. Its a problem which I think we very often encounter. Its
another driver for the "property bag" anti pattern. We, software
engineers, have a high esteem about knowledge and thats reflected
sometimes in a design in which almost every object can access lots of
knowledge( state) in the system. Distribution of the system state is
one of the most hard problems in OOD imho. For me this problem is more
easily solved if I see at as being a special kind of collobaration
problem. We can see it in human collaboration too.

At first sight we have people who are (over)active and dominant in
meetings and we have the other people who first listen and gather
information. The overactive people know that their judgements are
sometimes premature and wrong and the more passive people know that
they sometimes should take some risk.

If in a system there are lots of interactions centered mainly about
system state, if might indicate that system responsibilities are not
very well allocated and established. One of the subproblems of this
might be that we have a functional decomposition in which some objects
are librarians and others are the rapid reaction forces. Let your bar
or foo dont become one of those I would say and keep on looking for an
adequat allocation of system state.


Rick












\
Op 21 Sep 2006 04:58:31 -0700 schreef "Matt McGill"
<matt.mcgill@xxxxxxxxx>:

As a newcomer to OO design, I've been wrestling lately trying to wrap
my mind around the "Tell, Don't Ask" principle and the law of Demeter
for methods. I have been trying to avoid query/decision operations of
this nature:

Bar bar = foo.getFrozzledBar();
if (bar.isFranted()) // do something else

under the assumption (here I am trying to apply "Tell, Don't Ask") that
in this example foo's internal state (bar) is being exposed. Instead I
try to replace the above with a single, more meaningful method on foo,
containing the conditional in some form.

The question this has prompted me to ask: in what situations is bar a
part of foo's internal state, and in what situations is it really just
an object to which foo has an association? If bar *is* just an
associated object, is it then OK to navigate the association in the
above fashion?

- Matt McGill

.

Relevant Pages