Why are some types implemented as struct?

[Author]

I know the basic differences between a struct and a class, but
apparently not good enough to know why some types/concepts are
implemented as struct whereas most types are implemented as class.
For example, why is DateTime implemented as a struct? Why is BitArray
implemented as a class, but BitVector32 a struct?

In general, in OO design, how do we determine if we should use struct
or class?

 

[tal_mcmahon]

I know the basic differences between a struct and a class, but
apparently not good enough to know why some types/concepts are
implemented as struct whereas most types are implemented as class.
For example, why is DateTime implemented as a struct?  Why is BitArray
implemented as a class, but BitVector32 a struct?

In general, in OO design, how do we determine if we should use struct
or class?

Struct are placed in memory on the stack, therefore faster and do not
need to be cleaned up with garbage collection. Structs cannot be
extended and cannot extend anything else.

Classes Are on the heap, must be cleaned up and can be extended or
extend.

For most of us, a big "So what?"

I am assuming the choice af struct vs class is something that MS
thinks a lot more about in a framework than the common code grunt and
it comes down to first, performance and then to Symmetry in the code.

thats my take on it.

Tal

 

[Peter Morris]

Nearly every time I have designed something as a struct I have later
discovered I need to be able to change the values in it and ended up
converting it to a class, so now I just don't bother with them any more.

 

[Author]

I think that, in general, structs are for small things that use a fixed
amount of memory.

Hmm, sounds reasonable, at least with regard to BitArray (resizable)
and BitVector32 (not resizable). But is this the only possible reason
that some types are implemented as struct and others class?

I've read the other responses of my question, but they seem to be off-
topic. I would like to hear some guruish comment about my question.

 

[Peter Webb]

I think that, in general, structs are for small things that use a fixed
amount of memory.

Hmm, sounds reasonable, at least with regard to BitArray (resizable)
and BitVector32 (not resizable). But is this the only possible reason
that some types are implemented as struct and others class?

I've read the other responses of my question, but they seem to be off-
topic. I would like to hear some guruish comment about my question.

*****************************
I'm only a beginner myself, but nobody has mentioned that classes are
inheritable, whereas structs are not. If you are looking at this from an OOP
perspective, this is a huge difference.

 

[Peter Morris]

To be honest I don't even remember the problems I had, I just remember that
every time I have used them I have ended up switching to classes so now I
don't bother.


Pete

 

[Pavel Minaev]

In general, in OO design, how do we determine if we should use struct
or class?

A few distinguishing traits:

1) It is data-centric, not behavior-centric - e.g. Point is just a
tuple of two ints, Person is an entity with encapsulated operations.
Most methods on structs are just helpers to manipulate data, and could
usually be refactored as external methods. Most methods on classes
should encapsulate business logic related to entities those classes
model.

2) It has no identity - two structs are equal if the data within is
the same; for two structs with the same data, there is no way to
distinguish them, and using one in place of the other should give
identical results for any operation. C# enforces this by requiring
structs to define at least one field (since two identityless objects
which don't have data cannot be distinguished at all, so the result is
effectively a singleton). For example, if you get a Point with X=2 and
Y=3 from the first method, it is guaranteed that whether you pass that
same Point on to the second method, or create your own new Point with
the same values of X and Y and then pass that to the second method,
the actions performed by the second method will be exactly the same.
On the other hand, if you have two different Person instances, they
typically refer to two different people, even if their names (and
other data) match, so passing one instead of another to a business
method will do a different thing. In C#, this manifests itself in the
fact that classes have operator== which compares references (i.e. does
an identity comparison), and default implementation of Equals() for
classes also does reference comparison, while for structs Equals()
compares values of all fields, and there is no way to do a reference
comparison.

3) It is atomic with respect to updates - you cannot take an existing
Point and change just the X coordinate - the result would always be a
new Point. In C# terms, this means that structs are immutable (this
isn't enforced by the compiler, but is strongly recommended to follow
the practice nonetheless).

Simply put, the design difference between a struct and a class is the
difference between raw data (tuple, record, etc) and an entity. The
line can be blurry sometimes, but usually it is fairly obvious for
every specific case.

Of course, in real world, decision on using class vs struct is often
made for performance reasons - a good example is List<T>.Enumerator,
which is a struct, though it doesn't really fit the definition above.

 

[Author]

A few distinguishing traits:

1) It is data-centric, not behavior-centric - e.g. Point is just a
tuple of two ints, Person is an entity with encapsulated operations.
Most methods on structs are just helpers to manipulate data, and could
usually be refactored as external methods. Most methods on classes
should encapsulate business logic related to entities those classes
model.

2) It has no identity - two structs are equal if the data within is
the same; for two structs with the same data, there is no way to
distinguish them, and using one in place of the other should give
identical results for any operation. C# enforces this by requiring
structs to define at least one field (since two identityless objects
which don't have data cannot be distinguished at all, so the result is
effectively a singleton). For example, if you get a Point with X=2 and
Y=3 from the first method, it is guaranteed that whether you pass that
same Point on to the second method, or create your own new Point with
the same values of X and Y and then pass that to the second method,
the actions performed by the second method will be exactly the same.
On the other hand, if you have two different Person instances, they
typically refer to two different people, even if their names (and
other data) match, so passing one instead of another to a business
method will do a different thing. In C#, this manifests itself in the
fact that classes have operator== which compares references (i.e. does
an identity comparison), and default implementation of Equals() for
classes also does reference comparison, while for structs Equals()
compares values of all fields, and there is no way to do a reference
comparison.

3) It is atomic with respect to updates - you cannot take an existing
Point and change just the X coordinate - the result would always be a
new Point. In C# terms, this means that structs are immutable (this
isn't enforced by the compiler, but is strongly recommended to follow
the practice nonetheless).

Simply put, the design difference between a struct and a class is the
difference between raw data (tuple, record, etc) and an entity. The
line can be blurry sometimes, but usually it is fairly obvious for
every specific case.

Of course, in real world, decision on using class vs struct is often
made for performance reasons - a good example is List<T>.Enumerator,
which is a struct, though it doesn't really fit the definition above.

Finally, an in-depth comment. Thanks a lot. One has to have a very
strong analytical mind about objects/abstract concepts of the real
world in order to be a good OO designer.