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.

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.

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.

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.

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.

In C#, a method that expects an object of an “immutable” type should not have a parameter of an interface type because C# interfaces cannot specify the immutability contract. Therefore, the guideline you are proposing itself is meaningless in C# because you cannot do it in the first place (and future versions of the languages are unlikely to enable you to do it).

Your question stems from a subtle misunderstanding of Eric Lippert’s articles on immutability. Eric did not define the interfaces IStack<T> and IQueue<T> to specify contracts for immutable stacks and queues. They don’t. He defined them for convenience. These interfaces enabled him to define different types for empty stacks and queues. We can propose a different design and implementation of an immutable stack using a single type without requiring an interface or a separate type to represent the empty stack, but the resulting code will not look as clean and would be a little less efficient.

Now let’s stick to Eric’s design. A method that requires an immutable stack must have parameter of type Stack<T> rather than the general interface IStack<T> which represents the abstract data type of a stack in the general sense. It’s not obvious how to do this when using Eric’s immutable stack and he didn’t discuss this in his articles, but it’s possible. The problem is with the type of the empty stack. You can solve this problem by making sure that you never get an empty stack. This can be ensured by pushing a dummy value as the first value on the stack and never popping it. This way, you can safely cast the results of Push and Pop to Stack<T>.

Having Stack<T> implements IStack<T> can be useful. You can define methods that require a stack, any stack, not necessarily an immutable stack. These methods can have a parameter of type IStack<T>. This enables you to pass immutable stacks to it. Ideally, IStack<T> would be part of the standard library itself. In .NET, there is no IStack<T>, but there are other standard interfaces that the immutable stack can implement, making the type more useful.

The alternative design and implementation of the immutable stack I referred to earlier does use an interface called IImmutableStack<T>. Of course, inserting “Immutable” in the interface name doesn’t make every type that implements it immutable. However, in this interface, the contract of immutability is just verbal. A good developer should respect it.

If you are developing a small, internal library, then you can agree with everybody on the team to honor this contract and you can use IImmutableStack<T> as the type of parameters. Otherwise, you should not use the interface type.

I would like to add, since you tagged the question C#, that in the C# specification, there is no such thing as DTOs and PODs. Therefore, discarding them or precisely defining them improves the question.