Thread: What is the rationale behind `immutableCollection` family of methods, and the advantages of the particular pattern?

Hi all,

I have recently designed and implemented a group of my own reduced set and collections interfaces and classes. It was part of school assignment, but I used the opportunity to test some experimental strategies. I know well about Java Collections, but went a bit other way with immutability - the way I understand, the immutability of Java Collections is enforced AT RUNTIME - attempting to modify a set through an "immutable view" fails with a runtime exception, but there is nothing distinguishing a modifiable collection from an unmodifiable collection at compile (application design) time. The Java Collections way is all and well but there may be disadvantages to this, or at least I think they are - for instance, the code can still include 'add' and 'remove' calls to collections one knows to be immutable by design. As it has been more or less asserted (by research) that it is of benefit to be able to discover errors as early as possible, including being able to spot an attempt to modify an immutable collection, this pushed me to approach immutability differently.

And so I went another way with my collection framework - I have for instance an ImmutableCollection and ImmutableSet interfaces, which simply do not include any methods that modify the collection. In my project it all worked out fine, and so I wonder - what may be benefits and drawbacks of my design and the way Java designers did it?

Mind you, I do not advocate any particular strategy here, nor imply that I am a Java expert or anything - I just want an educated opinion on the matter, I could not really find any good material on the Internet.

I would like to be able to see patterns of application where my design is insufficient and lacking, so I can reason about my approach better.

I'm not sure I follow that Kevin.

Suppose I have a MyCollection type and an unrelated UnmodifiableMyCollection type with the same behaviour (except for anything that would modify the collection). There is nothing to stop MyCollection having some inner type that does all the UnmodifiableMyCollection stuff using the actual (modifiable) data of the MyCollection instance. MyCollection could then have a getView() method that returns an instance of the UnmodifiableMyCollection with no copying needed. The compiler would not permit any changes via the view, because the view didn't declare any mutating methods.

---

@OP: Suppose I had some code that worked with sets. Ie a method that took a reference to a set as an argument. Here's the thing: suppose my method did nothing that modified the set in any way. How should I declare the method? I could declare it as taking your Set argument - because, after all it works on sets, but then I couldn't pass a reference to your UnmodifiableSet. I could declare it as taking an UnmodifiableSet, but then I couldn't pass a Set.

I guess I'm after some way of telling the compiler "a set: modifiable or not, I don't care". Suppose I had a Set type that had no mutating methods, and a subtype ModifiableSet that did. Then I could write my method the way I want.

---

I haven't really thought about this a lot. And I'm a heretic who has some doubts about strong typing anyway...

Originally Posted by KevinWorkman

One benefit of the way Java does it is that it allows you to create unmodifiable views of your data structures, which is the whole point of the methods in the first place. If it returned some other UnmodifiableDataStructure, it would have to first copy over the Objects from the original data structure into the new one. This defeats the purpose of creating a view in the first place, as things like modifying the original data structure no longer change the view, which is how it's supposed to work.

I do see your point, but the way Java works makes sense if you think about it. Plus, if you don't like it, you're always free to come up with your own solution involving UnmodifiableDataStructures if you want.

I have views too, the difference is just that my views are unmodifiable by interface signature, while with Java Collections they are typed as Set or Collection or some other collection subclass type.

If by Collection interface you mean a sort of collection java defines - a MODIFIABLE collection, then no - an unmodifiable data structure cannot implement a writeable data structure. It is the other way around. It's a classical problem of read-write access - you have read-only and you have read-write. The latter implies the former, but the former does NOT imply the latter.

My Set interface extends UnmodifiableSet. This makes it possible for you to declare a method taking in an UnmodifiableSet, and it will accept a Set just fine.

Yes. I think that's what I was trying to get at with a Set supertype and ModifiableSet subtype. Just with a change of names: I wouldn't call the supertype "unmodifiable" if it allows subtypes to declare mutating methods. My instinct is to call it Set ... but it's just a matter of names.

Whatever you call them the important thing is that the supertype not declare mutating methods.

I really don't know why the rationale behind the Java way of doing things.