Question about "data hiding" OOP paradigm issue

[michaelb@xxxxxxxxxxxxx (Michael Brundage)]

Note, however, that methods receiving the ConstMyClass object can still
attempt to downcast to the mutable MyClass and then perform the nonconst
operation.  To be 100% safe, you need to create an opaque wrapper class that
delegates all the const operations to ConstMyClass and hides the original
object reference (thwarting downcasting).


michael
brundage@xxxxxxxxxxxx

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


> From: Sordini Emmanuele [mailto:Sordini.Emmanuele@xxxxxxxxxxxxxx]

> 1)	When I call mc.doSomething() the state of mc is changed, and so is
> the state of theObject. Or am I wrong? Feeding the setter with a reference
> to mc is quite performance-effective, but clearly breaks OOP visibility
> rules.
> 2)	If, on the other hand, I passed the setter a copy of mc, that would
> ensure respecting the rule but would generate some memory and performance
> overhead, which is not advisable given Java's generally poor scores.
>
> Anybody have any opinions / hints?

It's impossible to give a general recommendation, it really depends on the
semantics of your class. You correctly identified the trade-offs :

- pass by reference : efficient, but possibility for the object to be
modified
with side-effects
- pass by value (clone) : no side-effects, but probably unnecessarily slow

The typical way to deal with this problem is the Immutable idiom. Break your
class in two parts, one being read-only and which contains exclusively
"const
member functions" to use C++ terminology :

class ConstMyClass {
  public Object getValue() { ...}
};

class MyClass extends ConstMyClass {
  public setValue(Object o) { ... }
}

Then, just pick the appropriate type in your method's signatures.

Does this answer your question ?

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



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

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