(How)
C^# You Are - 5 August 2007

1. Why would you create a nested type?  Answer

   Nested types in .NET (C#) are generally not recommended (unlike some languages like C++).   There are cases where they can be useful though.  In almost all cases a type should be nested only if it is implicitly tied to the owning type, would not be useful outside the owner and is not directly exposed to clients.  A nested type should be used to provide an implementation for some functionality of the owning class.  In rare cases a nested type is also useful for implementing functionality that is relent upon implementation details of the owning type.  A nested type has access to the implementation details without messing up the public interface of the owner.

   An enumerator of a collection class is generally implemented as a nested type.  An enumerator is returned whenever a collection needs to be enumerated.  While the collection could implement the functionality itself it makes sense to separate the collection implementation from its enumeration.  Furthermore since the enumerator type itself is never accessible to the caller but rather an interface is used a nested type is appropriate.  The enumerator is specific to the collection so a standalone type would not be very beneficial.

2. When would you use an integer type rather than an enumeration for managing a range of values?  Answer

   Enumerations should be used whenever the range of values is known at compile time but there are limits to what an enumeration can do.  If the range is large (say over 255) then an enumeration is going to be almost too large to be of much use (think Color here) to most people.  Sometimes the actual range isn't known until runtime so an enumeration is not useful either.  The key to enumerations is that the values must be known at compile time.  If they aren't known at compile time then an integral value (perhaps in combination with other information) will be needed.

3. When would you want to seal a class?  Answer

   Some people are completely against sealed classes.  The fact that sealed classes are slightly faster than non-sealed classes is simply an implementation detail that should not be used in determining when a class should be sealed or not.  You should seal a class when extending its functionality would not be beneficial.  In most cases a class can be extended beyond what the original designers imagined so some general guidelines might be better. 

   If the class has no overridable methods or does not add any new overridable methods then it should probably be sealed.  Except for extending the functionality deriving a new class won't be that useful.  With the advent of extensibility methods in v3 this reason will not be that useful.  My opinion is that you should seal a class if you don't expect or want it to be extended.  Writing extensible classes can be challenging.  Should you make a method virtual or not?  Should you write a single method to perform some functionality or break it up to allow multiple extensibility points?  The questions go on and on.  In many cases it just doesn't make sense to make a class extensible so mark it sealed.

4. When would you want to make a property virtual?  Answer

   In general I am against making properties virtual altogether.  The problem with virtual properties is that both the getter and setter are virtual.  Virtual properties can not be inlined by the compiler (today at any rate).  Therefore, for a simple point of extensibility, you have negatively impacted the performance every time a property value is retrieved.  If a property can be inlined then it is effectively a field when it comes to performance. 

   I believe the better approach is to leave all properties nonvirtual.  If you want to provide an extensibility point to property setting (get is rare) then either introduce a protected property that is virtual or use a virtual method to allow derived classes to set the property value.  Here is an example of either approach.

   //Option 1
   class MyClass
   {
      public string Name
      {
         get { return m_strName; }
         set { SetName(value); }
      }
   
      protected virtual void SetName ( string value )
      { ... }
   }
   
   //Option 2
   class MyClass
   {
      public string Name
      {
         get { return m_strName; }
         set { NameCore = value; }
      }
   
      protected virtual string NameCore
      {
         get { return m_strName; }
         set { m_strName = value; }
      }
   }
   

   An important point.  If you truly need to provide an extensibility point for setting AND getting a property value then making the property virtual is reasonable.  However this is, in my experience, rare.  There is no real benefit in calling a virtual method from a property getter/setter so don't try working around the problem that way either.  Notice that in the sample above for option 2 the non-virtual and virtual getters both did the same thing.  If the non-virtual getter had called the virtual getter then we would have accomplished nothing.

5. When would you want to use mixed accessibility for a property?  Answer

   I'm not a big fan of this feature (added in v2) but it is occasionally useful.  Pretty much the only combination that I recommend is a public getter with a private setter.  In all other cases I recommend that you expose a public property with a getter and a protected property with a getter and setter.  This takes a little more code but, in my experience, is easier to understand, document and work with.

   class MyClass
   {
      //Publicly visible but can only be set by derived classes
      public string Name
      {
         get { return NameCore; } 
      }
      protected string NameCore
      {
         get { return m_strName; }
         set { m_strName = value; }
      }
   
      //This is reasonable because documentation and public usability isn't a concern
      public int Id
      {
         get { return m_Id; }
         private set { m_Id = value; }
      }
   }

    

6. When would you expose a field directly from a class?  Answer

   The only time it is recommended that you expose a field from a class directly is when the field is readonly or a constant.  In these cases a property provides little benefit.  However be aware that if you ever need to change the field to a property (in order to add code to the getter, for example) then all clients will need to be recompiled.  Therefore only expose readonly/constant fields that will truly never change.

7. When would you use a read-only field over a constant field?  Answer

   In general I recommend readonly properties over constants.  Constants have the following restrictions.

   Constants must be evaluatable at compile time
   Constants must be simple types
   Constants can not change without recompiling clients

   In general prefer a readonly field.  In both cases the field can not be edited by users but a readonly field can be initialized at runtime allowing for just about any type to be a readonly property and yet still allowing for full configuration of the field.  The only real downside to a readonly field is that it is slightly slower than a constant field but, since it has the same performance as properties, should not really be a determining factor.

8. When would you use the new keyword on a class member?  Answer

   In a word, never.  There are some who will argue that it is the only solution for scenarios A, B or C.  While I agree it is the only solution in some cases I can not justify the complications the new keyword adds.  It can be difficult to explain to new developers, difficult to document and difficult to debug when something goes wrong.

   If you don't know what the new keyword does on a class member then don't worry about it.  It is better that you don't know.  Instead find another workaround.  I would prefer an ugly workaround that works 100% of the time to one that is easy but doesn't always work.