[
Lists Home |
Date Index |
Thread Index
]
On Wednesday 23 October 2002 13:35, Simon St.Laurent wrote:
> Interesting perspective. While I do occasionally tweak
> public/protected/private for performance reasons, especially in J2ME, my
> days spent in XML have made it very hard for me to consider making
> anything private, and even protected requires some thought.
One argument for privatising every field in Java is that if you then
laboriously write pairs of get... and set... methods for each field then you
can (later) put in consistency checks for valid field values, automatic
updating of indices, security checks, etc. by modifying or overriding those
get/set variables.
Ideally, of course, one would have a language where foo.bar = baz is just a
shorthand for foo.setBar (baz) and foo.bar is short for foo.getBar (), like
my beloved Dylan, since then you can declare fields public or public-read
private-write as you see fit and still add behaviour later. Or remove the
actual field storage altogether and replace it with a computation.
In an app I wrote, most nodes in a tree have a string field for their name,
but one in particular has its name computed from its other properties since
those nodes are automatically generated. For simplicity we have a string name
and getName () method in the abstract node class, and in the node that
doesn't have an explicit name we override getName () and have a wasted String
field flapping around. Wasn't worth the effort of having AbstractNode and
AbstractNodeWithName classes.
> One of the key features of XML as a textual format is the exposure it
> gives to information. While it's certainly possible to deliberately
> obfuscate an XML document, I haven't seen that done in practice, and
> there's certainly no compiler to enforce it.
*cough* Microsoft Word export to HTML with XML 'styling' metadata *cough* :-)
> Giving someone an XML document says that you trust them far more than
> giving someone a Java object with private data. Recipients of XML
> documents are free to do what they like with them, without the
> distinctions created by public and private portions of interfaces.
private can be abused, sure, and often is. But I think that's an issue of bad
language design and poor education rather than a problem with the idea of
data fields being private.
> It's a pretty amazing thing, I think.
What's amazing to me is truly reusable objects; the original dream of OO, but
languages and developers have failed to meet it :-)
Not exposing enough in the interface is bad, yes, but I don't think that
making it impossible to hide stuff behind a clean abstraction layer is the
answer.
ABS
--
A city is like a large, complex, rabbit
- ARP
|
