Links

Lists

Latest Updates

Ruby On Rails List
Python list
Advanced Java
The JavaScript List
Apache Users
Full Disclosure
Linux Security

Search the archives!


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Question about "data hiding" OOP paradigm issue


  • From: michaelb@xxxxxxxxxxxxx (Michael Brundage)
  • Subject: Question about "data hiding" OOP paradigm issue
  • Date: Thu, 30 Mar 2000 14:47:51 -0800

It was not clear to me whether the original poster
was concerned entirely with OO purity, or perhaps also
OO security.

If you're passing an object to external code and require
that the object will not be modified (e.g., say you're an
applet host and passing a shared object to an applet) then
you must use opacity to be safe.  Attempting to hide
through a superclass or superinterface is not enough.

Otherwise, sure, your solution will prevent misuse of an
object intended to be const.  (Until the developer
decides s/he needs to modify the object or access some
other method on it that isn't availble through the
interface passed, and downcasts to get at it anyway.
Downcasting is a perfectly legal, and commonly used
throughout Java and the JCL.  Except for suggestive
class names or comments or conspicuous warnings in
the documentation, the library designer cannot
communicate the intent that the interface not be
downcasted.)


michael

-----Original Message-----
From: Cedric Beust [mailto:Cedric.Beust@xxxxxxx]
Sent: Thursday, March 30, 2000 2:24 PM
To: Michael Brundage; Advanced-Java@Xcf. Berkeley. Edu
Cc: Sordini.Emmanuele@xxxxxxxxxxxxxx
Subject: RE: Question about "data hiding" OOP paradigm issue


> From: Michael Brundage [mailto:michaelb@xxxxxxxxxxxxx]

> Note, however, that methods receiving the ConstMyClass object can still
> attempt to downcast to the mutable MyClass and then perform the nonconst
> operation.

People who do that deserve whatever they get :-)

More seriously, I am a trusting kind of a guy and I tend to think that a
developer is a reasonable person who knows what they are doing and I
personally
feel quite angry when someone doesn't return the favor to me (e.g. by
declaring
their methods final).

Sometimes, a user might have a very good reason to "cast away const" and you
shouldn't make it nearly impossible for them to do so (you can find another
justification of this leniency in the fact that C++ allows both const_cast<>
and the "mutable" keyword).

Don't try to protect people from their mistakes, it's an uphill battle. And
it
will upset good programmers.

--
Cedric
http://beust.com/cedric

---
To unsubscribe, mail advanced-java-unsubscribe@xxxxxxxxxxxxxxxx
To get help, mail advanced-java-help@xxxxxxxxxxxxxxxx