There seem to be a growing awareness about the benefit of immutability. Particular cases where immutable objects are much welcome are for instance in the case of value objects or for defensive copying. The problem is that immutable object don’t really go well with the object paradigm.
Let’s consider an application, which need to deal with the concept of revision. A revision is composed of a major and a minor revision number, e.g. “1.4”. This is typical candidate for a value object. The only sensible methods that deal with revision are inc which increases it, and promote which jumps to the next major version (“1.3” -> “2.0”). I will consider only inc in this post.
Here would be the (trivial) code in Java:
public class Revision
{
private final int major;
private final int minor;
public Revision( int major, int minor ) { ... }
public Revision inc() {
return new Revision( major, minor+1 );
}
}
This is however only a ad-hoc solution. This does not work well with polymorphism for instance: if a subclass of Revision is created, say NameRevision, calling inc on an instance would result in a Revision not NameRevision. This problem can be solved in other ways, and would for instance not appear in Smalltalk where instanciation would be done with super.basicNew on the class-side. But this just shows how mainstream OO language are not designed for immutability.
How would that be in a functional language such as Clojure? A map would probably be used to hold the major and minor number and the inc function would be as simple as setting a new value to the minor key in the map. Because any data modification results in a new structure, we don’t have the explicity make a difference between creating and modifying a structure. See my discussion on persitente data structure
(defn create-revision [] (hash-map :minor 1 :major 0)) (defn inc-revision [r] (assoc r :minor ( + (get r :minor) 1 ))
Note that the inc function is “polymorphic” in the sense that if I pass a map with :minor, :major and :name, I obtain a copy which has the three keys values.
The fundamental mismatch between OO and functional programming is that assignment has different semantics. In OO, assignment change the data in-place. In functional programming, assignments result in a copy.
And what if assignment would also result in a copy in OO? That sounds a bit contradictory to the OO spirit, but well, let’s give it a try…
If assignments result in a copy, this means that something like this.field = “newvalue” actually returns a new instance of the object, right? We could then imagine a class like this:
public class immutable Revision
{
int major;
int minor;
public int getMajor {
return this.major
}
public Revision setMajor( int value ) {
// assignment result in a copy!
return ( this.major = value );
}
// same for minor
public Revision inc() {
return this.setMajor( this.getMinor() + 1 );
}
}
We can somehow see that a generalized form of the builder pattern, and it fit well with fluent interface:
Revision r = new Revision( 1, 0 ); r.inc(); // return 1,1 r.inc(); // return 1,1
But
Revision r = new Revision( 1, 0 ) .inc() .inc(); // return 1,2
Note the keyword immutable that is necessary to specify the semantics of assignment for the class (there will indeed always be some mutable classes).
We now have two semantics for the assignment, one producing a copy and one changing the data in-place.
That sounds logical, that all classes in class hierarchy share the same mutability. Assigning a field from a subclass or a superclass should indeed produce the same result. But at the same time, this also means that we have two Object types? One mutable and one immutable? Hmm…
Another sound restriction for such a language would be to have assignment restricted to this. Something like obj.field = "newvalue" would be forbidden. This is anyway a good practice.
Also assuming that the language supports closures, do they fit in the picture? I would say yes, but I’m not sure. Given the signature of the closure is determined (it’s a function after all), and it cannot access any field of the object directly, so the semantics should be consistent. This would however require a bit more formalization to ensure there is no hole…
Like in some other post, I don’t know if the idea presented here hold for real. But I do like immutable object even in OO, and think that OO language lacks supports for such design. Current solution for immutable object is ad-hoc, but we could imagine blending functional programming and OO a bit more, resulting in some object having a hybrid behavior. Such object would essentially be immutable data structure embedding at the same time the function that corresponds to them, which still fit the equation Object = Data + Logic.
More About Immutability
- To mutate or not to mutate?
- Frozen object in ruby
- Java.next : immutability “But the benefit of using immutable data increases when you compose objects together. If you wanted to compose the synchronized version with another object, you would have have to dig back into the internals of both objects, study their locks, and pick a new lock strategy to cover the two objects together. Composing operations with immutable objects is much easier.”
://ewernli 