Re: Immutable object returned by methid
Larry Coon wrote:
I have a question about immutability, or at least, a question
about the right way to implement the concept I have in mind.
The folllowing is a distilled example of a more complex problem.
Your distillation has an uncomfortably high level of
contaminants. I don't know which were present in the mash
and which were introduced by the filthy dirty still, so I'll
just throw bleach at all the scummy spots I see.
Suppose I have some bean class called Something:
class Something {
private int value;
public Something(int value) { setValue(value); }
public void setValue(int value) { this.value = value; }
It is Very Bad for a constructor to call an overridable
method. Add `final' to the class or to the setValue method,
or use a `private reallySetTheValue' method called by the
constructor and perhaps by setValue. Don't give a subclass'
overriding method any chance to see an incompletely initialized
Something object.
public int getValue() { return value; }
}
Now suppose I have a set of business rules I want to
enforce, so I create a class Manager to encapsulate a
Something and enforce those business rules. Just as
an example, let's say the business rule is that the
Something value has to be even, and is bumped by one
if it's not:
class Manager {
private Something managedSomething;
public Manager(Something s) {
setSomething(s);
}
public void setSomething(Something s) {
if (s.getValue() % 2 != 0)
s.setValue(s.getValue() + 1);
managedSomething = s;
}
It is Very Bad for a constructor to call an overridable
method.
public Something getSomething() {
return managedSomething;
}
}
Other parts of the application are free to create
and mess with Something objects, and for most of
the application the "even" business requirement
doesn't exist. But for the cases where that
requirement DOES exist, you create a Manager, and
let the Manager manage the Something.
Problem is, clients can change the value and avoid
the business rule via:
manager.getSomething().setValue(21);
The problem is that you are trying to "wrap" a Something
while at the same time allowing the rest of the program to
"unwrap" it. There are two (at least) approaches to keeping
your wrappers impenetrable:
public class ManagedSomething extends Something {
public ManagedSomething(int value) {
setValue(value);
}
public final void setValue(int value) {
super.setValue(value % 2 == 0 ? value : value + 1);
}
}
This approach introduces a new ManagedSomething class, which
"is a" Something but with special characteristics. Note the
absence of a getSomething() method; there is no way a user of
this class can get hold of the "naked" Something underlying it.
Another approach:
public class Manager {
private Something thing;
public Manager(Something s) {
thing = new Something (s);
setValue(s.getValue(s));
}
public final void setValue(int v) {
thing.setValue(v % 2 == 0 ? v : v + 1);
}
public int getSomethingValue() {
return thing.getValue();
}
}
This uses the "has a" instead of "is a" relation. The
Manager hides a private Something inside its skin somewhere --
note that it doesn't even accept a Something passed in from
the outside, but instead makes its own private equivalent
copy. If you wanted to add a getSomething method, you'd do
it like
public Something getSomething() {
return new Something(thing.getValue());
}
.... so that only copies of the internal Something, not the
carefully-guarded original, could ever escape your control.
Here's where my immutability question comes up --
if manager.getSomething() returned an IMMUTABLE
Something, then all would be well. Is there a
way to make the return value from a method call
immutable?
No, and even if there were it wouldn't help. Your original
Manager class accepts any Something object the caller hands to
it, and has no way to prevent the caller from retaining its own
references to that object and using them later:
// in the caller ...
Something s = new Something(1);
Manager m = new Manager(s); // bumps value to even
Something t = m.getSomething(); // assume t is immutable
assert t.getValue() % 2 == 0; // Manager's promise
s.setValue(-99); // un-Managed modification
assert t.getValue() % 2 == 0; // see "Maginot Line"
I think you're trying to solve a problem that you've solved
in another context with Technique X. Instead of trying to
replicate Technique X in a new context, take a step back and
observe that the new context solves the problem with Y instead.
When was the last time you bought a currycomb to keep your
automobile looking good?
--
Eric Sosman
esosman@acm-dot-org.invalid