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
Artima Forums.
Message:
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 ... Harald
Replies:
|