This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.

Message:

what do dependencies mean for get/setters?

Posted by Harry Doherty on February 18, 2002 at 11:16 AM

Okay, so two dependent values should be
1. represented by two different variables,
2. the dependancy commented for the maintainers.
3. and proper values enforced by state-change mthds. (and javadoced for clients.)

It's this third client prespective point I'm unsure about.

For example you want to model two boolean values one of which implies the other. So you
1. use two (private) boolean variables and
2. comment the dependency in the source.
but
3. do you have two setters:
setAntecedent(boolean isTrue)
setConsiquent(boolean isTrue)
???

Should you then enforce the dependancy by:
opt1. possibly changing the value of one of the varables in the other's setter method?
or
opt2. if the setting would break the dependency throw an exception?
(an InvalidArgumentException?)

Thanks
Harry.

> Thanks for your comment. You make a good point that
> keeping non-independent variables separate creates
> the need for communicating the dependency. I
> think I'll modify somewhat my wording for the book.

> Of course, the responsibility for maintaining
> proper values in the to-some-extent-dependent
> variables (so long as the variables are private)
> lies with the methods. So the dependencies between
> the object's fields must be expressed in the
> code of the methods.

> But your point is how do you communicate the
> dependencies to other programmers? Just expressing
> the dependencies correctly in the code of the
> methods may still leave later readers of the code
> in the dark as to how the fields are being used.

> When I was in college, I had a part-time job
> grading student's Pascal programs, and I was
> supposed to dock them 5 points if they didn't
> comment their variables. But most of the comments
> in the variables were redundant with the variable
> names. A better kind of comment in the variables
> would perhaps be one that indicated the
> dependencies between the variables, such as:

> // innerCoffee indicates the amount of coffee in
> // the cup when needsWashing is false. When
> // needsWashing is true, innerCoffee is unused.

> I tend to prefer approaches to design that maximize
> readability without relying on comments, simply
> because a lot of times people don't bother to
> comment. That's one reason I like having two
> fields in this case instead of one. Absent any
> comments, at least I can look at the field names
> and ascertain that there are two attributes
> being modelled, and have an idea what the
> original programmer's intention was.

> Many years ago, I read in some book an anecdote
> that described how some poor manager lost his
> job because some programmer, many years before,
> had overloaded a single variable with multiple
> meanings. This programmer decided that the bank
> that would be using this program would never
> have as many as 10,000 accounts, so he used the
> account numbers < 10,000 to mean automatically
> send out bills to customers. One day several years later,
> the account numbers at the bank crept up past
> 10,000 and hundreds of customers found erroneous
> bills in their mailboxes.

> This design was not just a bad way to communicate
> what fields are used for, it was a time bomb
> because the program was likely automatically
> incrementing the account number each time. But
> it was a formative moment in my philosophy that
> we should "lean towards" modeling separate
> attributes in separate fields.

> Thanks again for your comments, Harald. If anyone
> else has an opinion on this one, please chime in.

> bv

> > 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