Is it bad or good to wrap mutable objects in immutable containers?

If I have parts of code that need to mutate the underlying data structure but then others that consume, not mutate the structure, is it good practice to create a wrapper which does not expose mutation operations?

Let’s say I have a tree and I only want higher up parts of code to be able to iterate it.

It’s a common approach. Conceptually, this is exactly the same principle as access specifiers and such, namely that you are limiting what operations can be used so that you know that the code is safe.

It can be a lot of effort and confusion to produce wrappers for each possible situation, so it’s only really worth it if there’s a fairly large body of code that needs this specific subset.

In general, it’s always a good thing to restrict methods as much as possible. The only question is how much effort it’s worth. This is not a tradeoff that can be made for you without really knowing how much effort it’ll cost you and how much code can use it.

Yes, encapsulation and immutability are good, but it’s important to understand why, because you’re sort of hitting just the wrong spot as Erik Meijer describes in his paper subtitled “Mostly functional” programming does not work.

Encapsulation is good when it works to decouple an interface from its implementation. It stops being good when you look at it to be some sort of security system protecting your public data from all those evil programmers down the hall who write the calling code. What often ends up happening in that situation is more code needs the unrestricted reference than you anticipated, and you end up with a lot of hacks converting it back and forth, or with the one unrestricted class trying to do way too much.

Immutability has a great number of benefits, nearly all of which disappear when you try to do it halfway. For example, you won’t be able to change the tree without resetting every iterator in every thread currently accessing it.

You’re really better off just making it immutable all the way down. This lets you take advantage of all the benefits of immutability, and you won’t care who has access to the insert/delete API, because they’re only changing their version of the tree.

Immutability has two effects: One, I cannot modify an immutable object. Two, nobody can modify an immutable object behind my back. If you hand me an immutable container containing a mutable object, then you can still modify that mutable object in the immutable container behind my back, so I gain nothing from the fact that it is immutable. You’d have to guarantee that once you create the immutable container, you are not going to modify the object anymore.

On the other hand, you can discuss whether an immutable container of mutable objects is really “immutable”. Like an immutable array of strings, where I can rely that the array will always contain the same strings, but I cannot rely on what the mutable strings contain. For many situations, that kind of immutability doesn’t actually give the guarantees that a consumer needs.

Immutability is not an end goal, in and of itself. Immutability is a tool. Like all tools, it has its appropriate uses, its advantages and disadvantages. Achieving it with existing mutable objects is harder than it looks.

Consider an ordinary array:

var pokerHand = new Cards[5];

We can make a data structure using an array as a backing field, and writing an indexer for it:

public class ImmutableArray<T>
{
    T[] array;

    public this T(int index)
    {
        get { return array[index]; }
    }
}

By eliminating the setter from the indexer, you’ve effectively made member access immutable, right? Well, not exactly. Because the item returned by the indexer is a reference type, you can still replace the object held by that reference type, and now you have a new object in that position in the array.

var item = myPokerHand[5];
item = new Card("KS"); // myPokerHand[5] now contains a new Card

To protect the contents of the original array, you have to make a copy of the object, and return that instead.

    public this T(int index)
    {
        get { return array[index].MemberwiseClone(); } // if you can.
    }

Note that MemberwiseClone is a shallow copy, not a deep copy. Doing this correctly could mean writing a Clone method that faithfully copies all of your object’s members, some of which may also be mutable references.

For all of these reasons, it is better to use the immutable collections already provided by the .NET framework, such as ReadOnlyCollection, collections that are designed from the ground up to be immutable.

For your own collections and objects, routinely restricting access to private members is generally a good thing, for reasons that I hope are obvious (cf. encapsulation).

Restriction of access is always a safe approach and can be considered good practice. This is known under the OOP paradigm as encapsulation and exists to prevent programming mistakes which are hard to detect, such as circumventing your own safety precautions in get/set methods by directly changing a variable. This also falls under the broader term of defensive programming, which is a programming paradigm where you eliminate potential errors by making it impossible to commit them in the first place.

There are many different way of achieving this and wrapping portions of code in immutable data structures is definately a viable option, depending on the language.

Filed under: softwareengineering - @ 18:30

Thẻ: c++, design, immutability

Thiết kế website giá rẻ

Danh mục

Is it bad or good to wrap mutable objects in immutable containers?

Further Reading