On a recent project, I tried to make better use of inheritance to simplify coding and improve the supportability of the end product. In the C# Programming Guide, inheritance is defined as a technique that “enables you to create new classes that reuse, extend, and modify the behavior that is defined in other classes.” In my case, I was seeking out ways to code a piece of business logic once and then share it using base classes. Sometimes, the base class is not even in the same assembly as the derived class let alone in the same namespace. I also try and use access modifiers to only show functionality on a need to know basis. By only showing the meaningful set of methods and properties, it makes the next programmers job easier as the intended way to use the class is clear. It’s actually easier to show than describe, so let’s get started.

Let’s start with our base class or “super class”. This is the class that contains the properties and methods used by its offspring or derived classes. An easy property to picture being shared is a UserId property. Let’s say that most, if not all work being done in the application needs to know who the user is. This might be for security, personalization, or to have on hand for interacting with data stores. Here is our base class with the UserId property.

There are a few things to know about and a few problems with our class. As the namespace suggests, the base class will actually be contained in a different assembly than our derived class. The C# language only supports two access modifier types for classes defined at the namespace level, public and internal. The default is internal, so our new class won’t be visible outside of the NewAssembly.dll library. In addition, the base class isn’t useful as a stand alone class. This is easy to fix by using the “pubic” access modifier and “abstract” keyword. This will make the base class visible outside the assembly, but it can only be inherited, not instantiated on its own.

Now, let’s look at the UserId property. Since within a class the default access modifier is “private”, the property won’t be visible outside of the class. We would like it visible to any derived class, but not outside of the class hierarchy. In addition, we want to set the value of the property when the class is instantiated, but not allow it to be changed afterwards. To accomplish this, we can use the “protected” access modifier and change the set action to private.

This creates a new problem. How should we set the value of the UserId property? For reasons I can’t fully cover here, I have become a fan of providing a default parameterless constructor, a loaded constructor with all required parameter and an initialization method to set base values. The parameterless constructor and initialization method need to both have the same access modifier. If they were both private, it would work but the parameterless constructor is really just a placeholder as it is inaccessible outside of the class. The loaded constructor can use the same modifier or provide even more access, but not less access.

Let’s take another look at the access modifiers we’ve chosen. The base class has a “public” modifier since anything less makes the base class useless outside of the assembly. However, the constructors are “protected”. This is because initialization of the base class needs to be managed by the derived class. The derived class will likely contain a public initializer, but the base class initializer should only be visible within the class hierarchy. It’s reasonable to let users of the derived class know whether the class is initialized and what the UserId value is. Therefor, these are both public. In the next article, we’ll inherit from our new base class.