I don't understand it...
Why do they need a common base?
I don't understand it...
Why do they need a common base?
I think, mainly in order to have a type to refer to any object. An argument of type object
could be a primitive type, a struct, a reference type, just anything. It is important to have such a type.
Then there are some common members that are implemented by every type, like Equals, ToString, GetHashCode. This could indeed be a common interface as well, but then you wouldn't inherit a default implementation.
Some reasons why many / most are:
To provide common members such as Equals, Finalize, GetHashCode, ToString....
To help with boxing....
Because its in the spec:
8.9.9 Object type inheritance
With the sole exception of System.Object, which does not inherit from any other object type, all object types shall either explicitly or implicitly declare support for (i.e., inherit from) exactly one other object type. The graph of the inherits-relation shall form a singly rooted tree with System.Object at the base; i.e., all object types eventually inherit from the type System.Object.
There are several benefits to this design approach.
The question presupposes a falsehood. They don't need a common base type. This choice was not made out of necessity. It was made out of a desire to provide the best value for the customer.
When designing a type system, or anything else for that matter, sometimes you reach decision points -- you have to decide either X or not-X. Common base type or no common base type. When that happens you weigh up the costs and the benefits of X to determine the net value, and then you weigh up the costs and the benefits of not-X to determine the net value, and you go with the one that was higher value. The benefits of having a common base type outweigh the costs, and the net benefit thereby accrued is larger than the net benefit of having no common base type. So we choose to have a common base type.
That's a pretty vague answer. If you want a more specific answer, try asking a more specific question.
Java and C# took a different approach to this. It's mainly to do with performance.
If you imagine that every object can be nullable, then it has to be a pointer to a value, which can be changed to a pointer to null. Now this means that for every object you need at least a pointer and a chunk of memory to store the value.
Java has the concept of a primitive value, which is NOT an object. It doesn't have a pointer and it isn't nullable. This breaks the OOP paradigm but performance wise makes sense.
C# (or more correctly the CLR + BCL) attempted a good compromise, the ReferenceType and ValueType derivations. Anything that derives from ValueType are treated like primitives to the CLR, avoiding having an object reference. However this value can still be treated like an object via boxing, allowing you to have the performance benefits of primitive types but allowing everything to be treated like an object.
The real key difference between these things is the semantics of passing parameters to methods. If everything is an object, then you are passing references to the object, i.e the object can be changed by passing it to a method. Primitives and C# value types are passed by value, so they are effectively copied into the method call and the original value is unchanged.
It's the standard story of development. Try and get it right first, then see if you can optimise it later once you see the bottlenecks. Having pass by value semantics also allow you to prevent coding mistakes from mutability. (eg. passing a class vs a struct in C#)
Every object in .NET shares common properties and methods. However, these are then divided into two categories: value types and reference types. Value types (ie, int) are stored on the stack, Reference types (ie, your custom class) are stored on the heap. Reference types store a reference to the actual data (thats on the heap). Value types directly contain their data.
You can read more over at MSDN:
As a side note to other "answers" a struct is a value type, that also inherits from object.
Maybe the answer is that its assumed that we are programming object-oriented style/paradigm? A ball is an object. A sword is an object. An employee is an object. A purchase order is an object.
Some companies design their .NET (or Java or Ruby or PHP) applications to inherit from a common base class, so that they can all be treated the same way in their system. If I remember correctly from back in my old Java days... all EJBs share the same base class so that they can be managed and identified uniformly.