object a = new Dog();
vs
Dog a = new Dog();
In both cases a.GetType()
gives Dog
.
Both
Both statements involve calling the default constructor of Dog
as you mention yourself; therefore, it is evident that in both cases a Dog
instance is constructed. This means that both statements end up initializing a variable with an identical instance (this is the part of the statement after the equals).
However, the statements also have another part: the declaration of a variable (this is the part of the statement before the equals). In statically typed languages such as C#, every variable -- more generally, any expression -- has a static type:
object a = new Dog(); // static type: object / runtime type: Dog
Dog b = new Dog(); // static type: Dog / runtime type: Dog
The compiler will not allow you to assign a value to a variable that it cannot prove is of the variable's static type, e.g. it would not allow
Cat c = new Dog(); // unless Dog derives from Cat, which we know isn't true
Since all reference types implicitly derive from System.Object
, assigning a Dog
to a variable of static type object
is OK. You can think of "static type" as what the object is "declared as". You can always determine the static type of something just by reading the source code; this is how the compiler does it.
Then there's also the runtime type of each variable (expression), which I mentioned above. This is the same in both cases, because after all in both cases we have created a Dog
. You can think of "runtime type" as what the object actually is. The runtime type of something cannot be determined just by reading the source; you only determine it while you program is running, hence the name. In C#, this is done by calling GetType
.
It should be obvious that the runtime type is something that you cannot do without¹; everything has to "be" something after all. But why bother with inventing the notion of static type?
You can think of static types as a contract between you (the programmer) and the compiler. By declaring the static type of b
to be Dog
, you tell the compiler that you do not intend to use that variable for storing anything other than a Dog
. The compiler, in return, promises to not let you violate your stated purpose and produces an error if you attempt to do that. It also prevents you from using d
in any way that not every kind of Dog
should support.
Consider:
class Dog {
public void Woof();
}
Dog d = new Dog();
d.Woof(); // OK
object o = new Dog();
o.Woof(); // COMPILER ERROR
The last line causes a compiler error because it violates the static typing contract: you told the compiler that o
can be anything deriving from System.Object
, but not all of the things deriving from that have a method Woof
. So the compiler is trying to protect you by saying "What are you doing there? I cannot prove² that whatever is in o
can woof! What if it were a Cat
?".
Notes:
¹ This does not mean that every object magically knows what it "is" in all languages. In some cases (e.g. in C++) this information might be used when creating an object, but is then "forgotten" in order to allow the compiler more freedom to optimize the code. If this happens the object still is something, but you cannot poke it and ask it "what are you?".
² Actually, in this trivial example it can prove that. But it won't choose to use this knowledge because honoring the contract of the static type is the whole point.