I: Question about "data hiding" OOP paradigm issue

[Sordini.Emmanuele@xxxxxxxxxxxxxx (Sordini Emmanuele)]

Hi!
First of all, thanks to everybody who replied to my question.
Although my post was more "OO-security-oriented", this topic involves =
both
issues. Anyway, in spite of the loads of improvements of Java over C++, =
I
sometimes miss the latter's feature of passing parameters by const =
reference
(i.e. const SomeClass& x...).

Bye
Emmanuele

-----Messaggio originale-----
Da:	Michael Brundage [SMTP:michaelb@xxxxxxxxxxxxx]
<mailto:[SMTP:michaelb@xxxxxxxxxxxxx]>=20
Inviato:	venerd=EC 31 marzo 2000 0.48
A:	'Cedric Beust'; Advanced-Java@Xcf <mailto:Advanced-Java@Xcf> .
Berkeley. Edu
Cc:	Sordini.Emmanuele@xxxxxxxxxxxxxx
<mailto:Sordini.Emmanuele@xxxxxxxxxxxxxx>=20
Oggetto:	RE: Question about "data hiding" OOP paradigm issue

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


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