Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Do not declare interfaces for immutable objects

[EDIT] Where the objects in question represent Data Transfer Objects (DTOs) or Plain Old Data (PODs)

Is that a reasonable guideline?

Up to now, I've often created interfaces for sealed classes that are immutable (data cannot be changed). I've tried to be careful myself to not use the interface anywhere where I care about immutability.

Unfortunately, the interface begins to pervade the code (and it's not just my code I'm worried about). You wind up being passed an interface, and then wanting to pass it to some code that really wants to assume that the thing being passed to it is immutable.

Because of this problem, I'm considering never declaring interfaces for immutable objects.

This might have ramifications with respect to Unit Testing, but other than that, does this seem a reasonable guideline?

Or is there another pattern I should be using to avoid the "spreading-interface" problem I'm seeing?

(I'm using these immutable objects for several reasons: Mainly for thread safety since I write a lot of multi-threaded code; but also because it means I can avoid making defensive copies of objects passed to methods. Code becomes a lot simpler in many cases when you know something is immutable - which you don't if you've been handed an interface. In fact, often you can't even make a defensive copy of an object referenced via an interface if it doesn't provide a clone operation or any way of serialising it...)


To provide a lot more context for my reasons for wanting to make objects immutable, see this blog post from Eric Lippert:


I should also point out that I'm working with some lower-level concepts here, such as items that are being manipulated/passed around in multi-threaded job queues. These are essentially DTOs.

Also Joshua Bloch recommends the use of immutable objects in his book Effective Java.

Follow Up

Thanks for the feedback, all. I've decided to go ahead and use this guideline for DTOs and their ilk. It's working well so far, but it's only been a week... Still, it's looking good.

There are some other issues relating to this that I want to ask about; notably something I'm calling "Deep or Shallow Immutability" (nomenclature I stole from Deep and Shallow cloning) - but that's a question for another time.

share|improve this question
+1 great question. Please explain why it is so important to you that the object is of that particular immutable class rather than something that merely implements the same interface. It's possible that your problems are rooted elsewhere. Dependency Injection is extremely important for unit testing, but it has many other important benefits which all go away if you force your code to require a particular immutable class. –  Steven Doggart Mar 6 '13 at 13:14
I'm slightly confused by your use of the term immutable. Just to be clear, do you mean a sealed class, which cannot be inherited and overridden, or do you mean that the data it exposes is read-only and cannot be changed once the object is created. In other words, are you wanting to guarantee that the object is of a particular type, or that its value will never change. In my first comment, I assumed to meant the former, but now with your edit, it sounds more like the latter. Or are you concerned with both? –  Steven Doggart Mar 6 '13 at 13:33
I'm confused, why not just leave setters off the interface? But on the other hand, I do tire of seeing interfaces for objects that are really domain objects and/or DTOs requiring factories for those objects...causes cognitive dissonance for me. –  Mike Brown Mar 6 '13 at 15:28
What about interfaces for classes that are all immutable? For example, Java's Number class allows one to define a List<Number> which can hold Integer, Float, Long, BigDecimal, etc... All of which are immutable themselves. –  MichaelT Mar 6 '13 at 15:28
@MikeBrown I guess that just because the interface implies immutability doesn't mean the implementation enforces it. You could just leave it up to convention (i.e. document the interface that immutability is a requirement) but you could end up with some really nasty issues if someone violated the convention. –  Baqueta Mar 6 '13 at 15:37
show 8 more comments

migrated from codereview.stackexchange.com Mar 6 '13 at 15:01

This question came from our site for peer programmer code reviews.

4 Answers

In my opinion, your rule is a good one (or at least it's not a bad one), but only because of the situation you are describing. I wouldn't say that I agree with it in all situations, so, from the standpoint of my inner pedant, I'd have to say your rule is technically too broad.

Typically you wouldn't define immutable objects unless they are essentially being used as data transfer objects (DTO), which means that they contain data properties but very little logic and no dependencies. If that is the case, as it seems it is here, I'd say you are safe to use the concrete types directly rather than interfaces.

I'm sure there will be some unit-testing purists who will disagree, but in my opinion, DTO classes can be safely excluded from unit-testing and dependency-injection requirements. There is no need to use a factory to create a DTO, since it has no dependencies. If everything creates the DTOs directly as needed, then there's really no way to inject a different type anyway, so there's no need for an interface. And since they contain no logic, there's nothing to unit-test. Even if they do contain some logic, as long as they have no dependencies, then it should be trivial to unit-test the logic, if necessary.

As such, I think that making a rule that all DTO classes shall not implement an interface, while potentially unnecessary, is not going to hurt your software design. Since you have this requirement that the data needs to be immutable, and you cannot enforce that via an interface, then I would say it's totally legitimate to establish that rule as a coding standard.

The larger issue, though, is the need to strictly enforce a clean DTO layer. As long as your interface-less immutable classes only exist in the DTO layer, and your DTO layer remains free of logic and dependencies, then you will be safe. If you start mixing your layers, though, and you have interface-less classes that double as business layer classes, then I think you will start to run into much trouble.

share|improve this answer
Code which expects specifically to deal with a DTO or immutable value object should use that type's features rather than those of an interface, but that doesn't mean there wouldn't be usage cases for an interface which is implemented by such a class and also by other classes, with methods that promise to return values that will be valid for some minimum time (e.g. if the interface is passed to a function, the methods should return valid values until that function returns). Such an interface can be helpful if there are a number of types which encapsulate similar data and one wishes... –  supercat Feb 22 at 20:00
...to have a means of copying data from one to the other. If all types which include certain data implement the same interface to read it, then such data may be copied easily among all the types, without requiring each to know how to import from each of the others. –  supercat Feb 22 at 20:01
add comment

It seems like an okay guideline, but for odd reasons. I've had a number of places where an interface (or abstract base class) provides uniform access to a series of immutable objects. Strategies tend to fall here. State objects tend to fall here. I don't think it's too unreasonable to shape an interface to seem immutable and document it as such in your API.

That said, people do tend to over-interface Plain Old Data (hereafter, POD) objects, and even simple (often immutable) structures. If your code has no sane alternatives to some fundamental structure, it doesn't need an interface. No, unit testing is not sufficient reason to change your design (mocking database access isn't the reason you're providing an interface to that, it is flexibility for future change) - it isn't the end of the world if your tests use that basic fundamental structure as-is.

share|improve this answer
add comment

I used to make a big fuss about making my code invulnerable to misuse. I made read-only interfaces for hiding mutating members, added lots of constraints to my generic signatures, etc., etc. It turned out that most of the time I made design decisions because I didn't trust my imaginary co-workers. "Perhaps someday they'll hire a new entry-level guy and he won't know that class XYZ can't update DTO ABC. Oh no!" Other times I was focusing on the wrong problem - ignoring the obvious solution - not seeing the forest through the trees.

I never create interfaces for my DTOs anymore. I work under the assumption that the people touching my code (primarily myself) know what is allowed and what makes sense. If I keep making the same stupid mistake, I usually don't try to harden my interfaces. Now I spend most of my time trying to understand why I keep making the same mistake. It's usually because I'm over-analyzing something or missing a key concept. My code has been much easier to work with since I gave up being paranoid. I also end up with fewer "frameworks" that required an insider's knowledge to work on the system.

My conclusion has been to find the simplest thing that works. The added complexity of making safe interfaces just wastes development time and complicates otherwise simple code. Worry about things like this when you have 10,000 developers using your libraries. Believe me, it will save you from a lot of unnecessary tension.

share|improve this answer
I usually save interfaces for when I need dependency injection for unit testing. –  Travis Parks Mar 6 '13 at 21:53
+1 Frameworks bad. Toolkits good. –  Steven Doggart Mar 6 '13 at 23:27
add comment

Code becomes a lot simpler in many cases when you know something is immutable - which you don't if you've been handed an interface.

I don't think that's a concern that the accessor implementer has to worry about. If interface X is meant to be immutable, then isn't it the responsibility of the interface implementer to insure that they implement the interface in an immutable fashion?

However, in my mind, there's no such thing as an immutable interface - the code contract specified by an interface applies only to the exposed methods of an object, and nothing about the internals of an object.

It's much more common to see immutability implemented as a decorator rather than an interface, but the feasibility of that solution really depends on the structure of your object and the complexity of your implementation.

share|improve this answer
Could you provide an example of implementing immutability as a decorator? –  Baqueta Mar 6 '13 at 15:27
Not trivially, I don't think, but it's a relatively simple thought exercise - if MutableObject has n methods that change state and m methods that return state, ImmutableDecorator can continue to expose the methods that return state (m), and, depending on the environment, assert or throw an exception when one of the mutable methods is called. –  Jonathan Rich Mar 6 '13 at 15:33
I really don't like converting compile-time certainty into the possibility of run-time exceptions... –  Matthew Watson Mar 6 '13 at 15:39
OK, but how can ImmutableDecorator know if a given method changes state or not? –  Baqueta Mar 6 '13 at 15:41
You can't be certain in any instance if a class which implements your interface is immutable with regards to the methods defined by your interface. @Baqueta The decorator has to have knowledge of the implementation of the base class. –  Jonathan Rich Mar 6 '13 at 15:41
show 2 more comments

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.