Using Shadowing in C#

Introduction

Shadowing is a useful tool for customizing classes when you want to keep some properties hidden from a third party, but allow your own developers access to specific regions of an inherited class.

Background

My employer specializes in online assessments that evaluate prospective employees for high-potential talent. We allow our clients to set up personality assessments for their prospective employees by passing an Assessment object to our systems through Web Services. When we moved to a new WCF model, we took an opportunity to make our assessment setup more friendly and flexible to our 3rd party developers.

Our new design used two classes: a lightweight assessment class for the customer, and a heavyweight class for internal use. The lightweight class inherited from an interface. The heavyweight class inherited from an abstract class which in turn inherited from the same interface. When the customer sends an assessment, the lightweight assessment class is cast to the heavyweight class and the heavyweight class automatically populates its properties from our database. This hides the database implementation from our third party vendors. In order to avoid future misuse of the heavyweight class, we built it with few set properties and designed it to to be created only by casting from the lightweight class.

But this presented an additional problem. Eventually, I had to get assessment information from our database with a Finished Assessment class. Most of this assessment information reused components from the Heavyweight class. How could I reuse the abstract class when it was absent of set properties? I couldn’t reuse the Heavyweight class since setting up a Heavyweight class required a new assessment.

The answer is shadowing.

Using the Code

Assume you have a section of code in your abstract class that has property which only contains a get, but no set:

public virtual Guid Company_Id { get { return _Company_Id; } }

Theoretically, you should be able to override it in an inherited class by doing this:

public override Guid Company_Id { get { return _Company_Id; } set { _Company_Id = value; } }

Right? Wrong. You can’t override something that isn’t there.

The correct way would be to use the new keyword in place of the override:

public new Guid Company_Id { get { return _Company_Id; } set{ _Company_Id = value; } }

This will allow you to shadow the set property without throwing an exception. You can set up classes that change the behavior of the inherited class by replacing the base member, yet retain the flexibility of the base class so that you can re-use your code.

Points of Interest

The lazy way of doing this would have been to simply add a set command in the abstract class and then override them to take them away in the Heavyweight class. But this could have also opened up tempting holes in the Heavyweight class which would have encouraged programmers to re-use it for all sorts of inappropriate things. With shadowing, the Heavyweight class stays heavy. The Finished Assessment class does its job. And the Lightweight class hides its complicated implementation from our customers.