This page contains an archived post to the Design Forum made prior to February 25, 2002.
If you wish to participate in discussions, please visit the new
Modeling the reality is not that easy ...
Posted by Harald M. Mueller on 20 Mar 1998, 1:00 PM
I liked your article about some basics. However, I'd like to comment on
"The especially valuable guideline for fields".
There is an underlying assumption in this guideline, namely that the values of any two
attributes are either fully independent or fully dependent. Independent here means that any combination of values of two attributes a1 and a2 is admissible and
makes sense; whereas for fully dependent attributes, the values of two attributes can be
computed from each other.
However, in reality, in many cases a partial dependence occurs.
Take the coffee cup: Let us assume that we want to model the coffee cup in a way that
when it needs washing, the amount of coffee is unspecified. The first implementation, with
the "specific value", does that perfectly. The second implementation, which separates
the washed status from the coffee amount, cannot model this.
So, the tight coupling between the attributes by putting them into one field appears(!)
to be advantageous sometimes.
The real question, of course, is: "When are two attributes *sufficiently* independent so
that they should be placed into two fields?" Observe that this is a question of *degree*
(and no longer an either-or question, as your guideline assumes).
The answer to this *is* to lean to your guideline, i.e. "When in doubt, use more fields".
*However*, the next thing you *have to do* is to specify exactly (formally, if possible)
the dependencies between the fields; e.g. "needsWashing == true => innerCoffee is undefined".
Why? Because if you do not do that, programmers will implicitly *assume* "sensible"
dependencies; and, of course, different programmers might assume different things.
Again the coffee cup: One might use innerCoffee as a temp variable when needsWashing is true;
another one might assume that the innerCoffee DOES have a meaning also in the case when
needsWashing is true. Both are in some sense "right", as each interpretation is a valid model.
Yet, their methods will quite forcefully clash when used together.
So the rule should be:
The especially valuable guideline for fields
Use a separate field to represent each separate attribute of a class or object.
If two attributes are only "somewhat separate", use two fields, but document the
dependencies between the fields' possible values carefully.
Two attributes count as "somewhat separate" if your team starts arguing.
There is much more to all that - theoretically as well as in practice -, but my comment
starts getting long ...