Newsgroups: comp.lang.java,comp.object,comp.object.logic
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news4.ner.bbnplanet.net!news.ner.bbnplanet.net!news.mathworks.com!uunet!in1.uu.net!world!bobduff
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Java public instance variables harmful?
Message-ID: <DoHIBL.3y6@world.std.com>
Organization: The World Public Access UNIX, Brookline, MA
References: <KRUSE.96Mar6131047@cms6.cern.ch> <4hkhnv$5ne@decaxp.harvard.edu> <4hqf90$o18@jalisco.optimum.net> <RMARTIN.96Mar11083147@rcm.oma.com>
Date: Mon, 18 Mar 1996 22:26:08 GMT
Lines: 23
Xref: glinda.oz.cs.cmu.edu comp.lang.java:32444 comp.object:46174 comp.object.logic:756

In article <RMARTIN.96Mar11083147@rcm.oma.com>,
Robert C. Martin <rmartin@oma.com> wrote:
>The upshot of all this is that it is almost impossible to forsee all
>the reasons why a member variable ought to be private.  Making it
>private is always safe.

But if you admonish people to always make it private, they'll end up
with SetX, GetX, SetY, GetY.  This doesn't seem any better.  Well, I
suppose you can override them, but it's still the wrong level of
abstraction.  (As you *pointed* out, SetXY is closer to the truth.  Or a
function taking X,Y and returning a point.)  To me, this admonition is
like the admonition "avoid gotos" from the '70s (which is still going
on...), but it misses the point of *why*.

>...  Making it public might be convenent, but
>cannot be proven safe.

I'm afraid nothing can be "proven" safe.

Anyway, why not have a language where you can declare a public variable,
but then override the get and set.  Such languages exist.

- Bob
