Immutable class with behavior

Question

I've just finished Effective Java and I loved it. I'm trying to refactor one of my programs to take advantage of what I've learned, and I have a lot of questions regarding immutability.

My program is largely built around a model class representing a reminder, which is stored in a content provider. This article suggests that, since it represents data held in the content provider, I could create an immutable class that simply calls through to the content provider. But for all I know this author is completely wrong and this is a terrible idea. It sounds to me like it would be very non-performant to be calling the content provider all the time, which then queries a sqlite database, and I'm disinclined to follow this pattern.

My other question regards several small classes I have where none of their members change after they are created, but they make asynchronous calls to system services, and return the response along an interface. Can a class like that ever be immutable? The class itself is stateless and never changes once created, but it calls other classes that are closely tied to device status.

Answer 1

Please don't follow the advice in that article.

The author is correct to advocate immutable objects. But to get the advantages of immutable objects, the object should be transitively immutable. That is, it should only keep references to other transitively immutable objects. It shouldn't be referencing data providers, and it certainly shouldn't be keeping its state on some other object in some misbegotten attempt to pretend to be immutable when it is not.

Immutable objects are nice primarily because they are easy to reason about. I know that once created they don't change. If its the same object as I had before, I know that nothing is different. I know that I can pass it other functions and not worry about them changing it.

The proposed solution in that article makes the supposedly immutable object act like a mutable object. Sure, it might not actually modify its own fields, but it still acting like a mutable object. I don't really care how it is implemented internally, its a mutable for all intents and purposes.

So, yes, from my perspective that site is full of terrible ideas. It wouldn't be performant, and it wouldn't have almost any of the advantages of immutable objects. All you would be doing is sacrificing simplicity and efficiency for misbegotten understanding of immutability.

My other question regards several small classes I have where none of their members change after they are created, but they make asynchronous calls to system services, and return the response along an interface. Can a class like that ever be immutable? The class itself is stateless and never changes once created, but it calls other classes that are closely tied to device status.

I would not call such a class immutable. Yes, its immutable in some sense because it doesn't change. But that is an implementation detail. It doesn't act like an immutable object. When I'm using that object elsewhere, I care about the interface, not the implementation.