A parallel discussion at the Lombok mailing list revamped some thoughts
and doubts about immutability. I'd like have some feedback about it.
Given that immutability is a "turtles all the way down" thing
("turtleness" in the following), a poster raised doubts about things
such as File. File is immutable for what concerns its internal state
(the path), but all methods that actually work on the related file don't
always return the same values (or do the same thing) because they refer
to the actual file which is mutable.
Such a class is regarded as mutable or immutable? Of course, I'm
interested in the practical purposes.
Curiously, the "anemic object" antipattern is something that would help
here. If you defined File only as a wrapper on a path, and FileSystem
another class which accepts a File as argument, you would have clearly
separated the mutable and immutable portions.
But I don't like anemic objects. When I can, I just separate the two
parts in two different objects, but they stay bound together. Referring
to some actual code that I'm not using in production but for some
tutorial, I have a:
FileModel fileModel = new FileModel("/foo/bar");
String path = fileModel.getPath();
String name = fileModel.getName();
and the above two methods are the only two specific methods of
FileModel. So far, it's anemic and immutable. Going on:
fileModel.as(Removable).remove();
long size = fileModel.as(SizedInBytes).getSize();
List<FileModel> children = fileModel.as(Composite).findChildren().results();
That as() is my way to deal with DCI and Semantic models. In simple
words, it just recovers a "role" of FileModel by referring to its
interface - as(Removable) is a shortcut for as(Removable.class). All the
roles in the example above are simple, stateless objects that work on
the real filesystem. Clearly, I've separated behaviours: FileModel on
its own encapsulates the really immutable portion, while roles keep the
remainder behaviours. But there's no turtleness in FileModel, because
there's only a single level of turtles (i.e., fileModel.as() always
returns the same thing for each role, but the returned object is not
immutable in the strict definition).
There are variations on the theme. Some roles are de facto hardwired in
FileModel; others can be dinamically injected by the context. But once a
role has been injected into a FileModel instance, it stays forever.
How do you comment about immutableness of FileModel? As said, there's no
turtleness. It's enough to say that FileModel is not immutable?
PS Another related question is about equals() and hashCode()... Are two
FileModel instances with the same path, but possibly different roles,
equals()? I'd say not. But this is another question, and more related of
the broken definition of equality in Java.
--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
java.net/blog/fabriziogiudici - www.tidalwave.it/people
[email protected]
--
You received this message because you are subscribed to the Google Groups "The Java
Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
