Choosing between immutable objects and structs for value objects

Question

How do you choose between implementing a value object (the canonical example being an address) as an immutable object or a struct?

Are there performance, semantic or

Answer 1

How do you choose between implementing a value object (the canonical example being an address) as an immutable object or a struct?

I think your options are wrong. Immutable object and struct are not opposites, nor are they the only options. Rather, you've got four options:

• Class
  • mutable
  • immutable
• Struct
  • mutable
  • immutable

I argue that in .NET, the default choice should be a mutable class to represent logic and an immutable class to represent an entity. I actually tend to choose immutable classes even for logic implementations, if at all feasible. Structs should be reserved for small types that emulate value semantics, e.g. a custom Date type, a Complex number type similar entities. The emphasis here is on small since you don't want to copy large blobs of data, and indirection through references is actually cheap (so we don't gain much by using structs). I tend to make structs always immutable (I can't think of a single exception at the moment). Since this best fits the semantics of the intrinsic value types I find it a good rule to follow.

Answer 2

As a rule of thumb a struct size should not exceed 16 bytes, otherwise passing it between methods may become more expensive that passing object references, which are just 4 bytes (on a 32-bit machine) long.

Another concern is a default constructor. A struct always has a default (parameterless and public) constructor, otherwise the statements like

T[] array = new T[10]; // array with 10 values

would not work.

Additionally it's courteous for structs to overwrite the == and the != operators and to implement the IEquatable<T> interface.

Answer 3

Factors: construction, memory requirements, boxing.

Normally, the constructor restrictions for structs - no explicit parameterless constructors, no base construction - decides if a struct should be used at all. E.g. if the parameterless constructor should not initialize members to default values, use an immutable object.

If you still have the choice between the two, decide on memory requirements. Small items should be stored in structs especially if you expect many instances.

That benefit is lost when the instances get boxed (e.g. captured for an anonymous function or stored in a non-generic container) - you even start to pay extra for the boxing.

---

What is "small", what is "many"?

The overhead for an object is (IIRC) 8 bytes on a 32 bit system. Note that with a few hundred of instances, this may already decide whether or not an inner loop runs fully in cache, or invokes GC's. If you expect tens of thousands of instances, this may be the difference between run vs. crawl.

From that POV, using structs is NOT a premature optimization.

---

So, as rules of thumb:

If most instances would get boxed, use immutable objects.
Otherwise, for small objects, use an immutable object only if struct construction would lead to an awkward interface and you expect not more than thousands of instances.

Answer 4

I actually don't recommend using .NET structs for Value Object implementation. There're two reasons:

• Structs don't support inheritance
• ORMs don't handle mapping to structs well

Here I describe this topic in detail: Value Objects explained

Answer 5

Structs are strictly for advances users ( along with out and ref) .

Yes structs can give great performance when using ref but you have to see what memory they are using. Who controls the memory etc.

If your not using ref and outs with structs they are not worth it , if you are expect some nasty bugs :-)