[
Lists Home |
Date Index |
Thread Index
]
"Simon St.Laurent" <simonstl@simonstl.com> writes:
> tblanchard@mac.com writes:
> >Based on a couple of other comments like objects "hiding away data" I
> >can see the reaction against compiler enforced encapsulation. Its bad.
> > Pure and simple. Public Protected Private is a menace to modern
> >software development ...
>
> 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.
I disagree. Making something private marks it as unimportant to the
user (who, as the saying goes, might be you in three months).
Reading through org.apache.xml.* JavaDocs, with hundreds of protected
fields and methods, it takes forever to understand what the data
model, or the intended use are. But at least you know that if
something is protected, you don't need to worry about it until you
decide to patch it. (Don't try to use it if you are extending, because
it will as often as not break things in very unexpected things, unless
it's there specifically as a 'hook' for extending)
> 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.
>
> 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.
Not all data in an OO object are "real" data that you might want to
send; much of that are procedural implementation details. Is your
recipient really interested in those integers you used as loop
counters?
Ari.
|
