tags:

views:

351

answers:

9

I don't understand it...

Why do they need a common base?

A: 

ToString. For example.

John Lockwood
+16  A: 

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.

Stefan Steinegger
Important, for example, for heterogeneous collections like HttpContext.Items, where you want to be able to put *anything* in there.
itowlson
Really, that example extends to _any_ example (eg I want a method to take a parameter of _any_ type). This is just one of the benefits of having some common expectations for _all_ types in the type system.
Nader Shirazie
A: 

Useful for Boxing and Unboxing

see reference

PostMan
+1  A: 

Some reasons why many / most are:

To provide common members such as Equals, Finalize, GetHashCode, ToString....

To help with boxing....

klabranche
Nice try, but no cigar. The question is "why does every class derive from object" and yes, every class derives from object.
Eric Lippert
Doh!!!! Fail on my part.... Thanks for catching that Eric.
klabranche
Removed my link to your post. :-)
klabranche
+3  A: 

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.

Nader Shirazie
"It's in the spec" doesn't cast much light on the design reasoning, which is what I think Tom is trying to get his head around: it just begs the question, "so why does the spec say that?"
itowlson
I was being a smartass. To answer "why is it in the spec", see Eric's response (http://stackoverflow.com/questions/1583482/why-does-every-class-in-net-inherit-from-object/1583524#1583524).
Nader Shirazie
+12  A: 

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.

Eric Lippert
"Best value for the customer" is the practical way of thinking about it, I guess. Elegance and well-structured design would seem to be the other. Indeed, there is a balance involved whichever way you consider things.
Noldorin
Spoken like a markting guy. Do you want to add some good and bad points for X and not-X? How do you measure the value of having a common base class or not having one?
Elegance and well-structured design are usually both practical and good for the customer; in fact, they are often signs that we've found the right solution. Not always, but usually.
Eric Lippert
Marketing is about creating demand for products and services; I did not attempt to do so. I'm speaking as a designer and implementor; I'm not sure what about that you think sounds like marketing. If what you want is a detailed analysis of the pros and cons of various aspects of type system design, I'd suggest that this is not the forum appropriate for a work of that length.
Eric Lippert
A: 

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#)

Spence
A: 

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:

http://msdn.microsoft.com/en-us/library/system.object.aspx

Kris Krause
A: 

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.

Kris Krause