Is it a different object or the same object with an altered property (mutable or not)?

Question

When I design the architecture of an application, I usually think about the nature of the objects and the interactions between them.

The way I currently think about mutability is to ask myself if changing a member changes the object altogether. A car can be repainted, but if you change the manufacturer it's another car.

Now, this problem arose while designing a simple application which draws a small animation. The animation is a line that grows in width up to some point, and then remains the same.

Assume there is a Line object, with a width member and drawing functionality. Now I have 2 approaches:

for (int newWidth = 10; newWidth < 1000; newWidth++) {
    line.setWidth(newWidth);
    line.draw();
}

, which means that width is a mutable property of the line, or:

for (int newWidth = 10; newWidth < 1000; newWidth++) {
    line = Line(newWidth);
    line.draw();
}

, which creates a new object (i.e. a different line) for every width.

As an overall performance, the second version looks more inefficient, but which one is better in terms of design?

Answer 1

The way I currently think about mutability is to ask myself if changing a member changes the object altogether.

I think this is your main problem. While the two questions are related, they are different from each other. There are benefits to mutability and immutability that mean both can be useful whether or not your object has identity.

But I think another issue you have in your design is that you've considered a couple of alternatives (mutable object that changes, immutable object that is replaced) but there are others to consider (specifically, immutable object that encapsulates the changes and therefore remains constant). Consider a different design for this problem where instead of the object having a width property it has a width function. Depending on how you're doing your animation, you could pass it either a frame number or a time as an argument, and then the Line can calculate itself how wide it should be at that point in the animation and has no need to change at all.

If you have different lines that need to behave differently you could either have an abstract Line superclass and subclasses for the different behaviours, or you could pass the Line a function reference as a parameter when you initialise it.

Answer 2

In Domain Driven Design, there is a notion of Entity object and Value object. To put it simply entity objects have lifetimes, are identified by special identificator and are mutable. While value objects are only identified by their value, are usually immutable and can be created/destroyed at any time. You are trying to decide whenever Line is an entity or value object.

But DDD is primarily concerned with complex domain logic. I would question it's usefulness in your case, which I believe would prefer ease of use and performance over extensibility and modularity.