c# Immutable classes in business applications

Question

Why and when do we need immutable (i.e. readonly) classes (I am not talking about string. I am talking about Business Objects) in business or database applications?

Can anyone give me a real-world example of a scenario?

Answer 1

Immutable types are easier to reason about than mutable ones - when you've got a reference to an instance, you know you can rely on it not changing. You can build up a functional style of working, where any mutation you would want to perform becomes an operation creating a new instance (just as it does with string) - those functional operations can be composed safely, with no concerns around what happens if one of the operations changes the object in a particular way which would harm the other operations.

Once you've made a decision based on the state of an immutable value, you know that decision will remain valid for that value, because the value itself won't be able to change.

Additionally, immutability is useful for threading - immutability avoids a lot of the concerns around data-races etc when you want to use a single object across multiple threads.

A lot of these benefits can be useful for business objects, but you do need to approach problems with a different mindset. In particular, if your database rows aren't immutable (i.e. you will be modifying rows rather than always creating new "versions" of rows) then you need to be aware that any given value may no longer represent the database state for that row.

Answer 2

Once you have printed out an invoice and issued it to the customer, that invoice is frozen in time forever. Any adjustments would need to be applied on a subsequent invoice.

Answer 3

Though Jon certainly makes a compelling case for the benefits of immutable objects, I'd take a slightly different tack.

When you're modeling a business process in code, obviously what you want to do is to use mechanisms in the code to represent facts about the model. For example, if a customer is a kind of person, then you'd probably have a Person base class and a Customer derived class, and so on.

Immutability is just another one of those mechanisms. So in your business process, think about what things happen once and then never change, in contrast with what things change over time.

For example, consider "Customer". A customer has a name. Does the name of a customer ever change? Sure. Customer names change all the time, typically when they get married. So, should Customer be an immutable class? Probably not. Logically, when a customer changes her name, you do not create a new customer out of the old one; the old customer and the new customer are the same object, but the name property has changed.

Now consider "contract". Does a contract ever change? No. An emendation to an existing contract produces a new, different contract. The dates, parties, clauses, and so on in a particular contract are frozen in time. A contract object could be immutable.

Now the interesting question is what to do when a contract mentions a customer, and the customer changes their name. It's the interactions between mutable and immutable objects that make this a tricky design problem.