Order of Construction

Comments 0

Share to social media

 

For me, inheritance is often a headache.  In particular, in what order is everything initialized?  Consider this short C# program.   It creates an instance of Dog, which derives from Animal.  Both Dog and Animal have an instance constructor, a class initializer (aka a static constructor), an instance variable, and a static variable. 

There are eight activities here:

  1. Dog instance constructor
  2. Dog class constructor
  3. Dog instance variable
  4. Dog static variable
  5. Animal instance constructor
  6. Animal class constructor
  7. Animal instance variable
  8. Animal static variable

The question is: ‘In what order are the eight activities run?’  Try working it out.  Anyway, the answer is:

  1. Dog static variable
  2. Dog class constructor
  3. Dog instance variable
  4. Animal static variable
  5. Animal class constructor
  6. Animal instance variable
  7. Animal instance constructor
  8. Dog instance constructor

There are two things I find surprising about this:

  1. Why do static constructors run from most derived class to least derived class, i.e. Dog then Animal?
  2. Why do instance variables get initialized before calling the parent’s instance constructor?

The answer to question 1 is that Dog’s class initializer has to be run since we are running Dog’s instance constructor, but execution of any type’s class initializer method will not trigger automatic execution of any class initializer methods defined by its base type.  Indeed, why should it?

The answer to question 2 is complicated.  Constructing instance fields in the most derived class first is the only way to ensure that readonly fields are initialized and then not changed.  Check out Eric Lippert’s blog for a decent explanation: http://blogs.msdn.com/ericlippert/archive/2008/02/15/why-do-initializers-run-in-the-opposite-order-as-constructors-part-one.aspx

Load comments

About the author

Jason Crease

See Profile

Jason Crease studied maths and computer Science at Cambridge University and joined Redgate several years ago as a Test Engineer. He specialised for some time in Testing .NET applications and was part of the team responsible for the development of ANTS Profiler and .NET Reflector. After working as a DevOps engineer supervising Redgate's own IT systems, he joined the DLM team, working on the practicalities of the management and automation of the application lifecycle.

Jason Crease's contributions