Introduction:

Sometime ago I had blogged about the benefits of wrapping v/s deriving.

To take the idea further, I decided to write a simple C# console application to show this implementation in terms of some code. I am assuming you had an opportunity to read the previous article, if not; this is really a good time to do so. The following article explains the code & its concept and a full source download is available. Just a note: This is not yet production-ready code.

Scenario:

Suppose that one of your really High Profile/Paying Customers (HPC) asks you to use their pet third party control (ThirdParty.UI.SomeControl) in the fancy new application you are creating for them. I am sure that you would not be arguing with them for more than a few minutes regarding this point if you want to keep the contract.

So, you go back to the drawing board to consider how you can minimize the exposure & dependence your application would have because of using this third party control.

Solution:

Let us start by first inheriting from this third party control (assuming it is a not a sealed class):

The interesting pieces of this code are:

1. We have inherited from the ThirdParty.UI.SomeControl so that we can extend its behavior if needed (trust me – the HPC will find the toughest possible extension)
2. The inherited class is marked internal so that it can be available only within the UI control library namespace & will not be used anywhere in our application (You do have a control class library for your application, right?)
3. The class implements the IInternalControl interface which ensures that all publicly visible members of the internal control class are implemented. We will get back to this interface in just a bit.

Now that this is done, let us write some code to create a control which will be consumed in our application like so:

The interesting pieces of this code are:

1. The control has a private read only instance of IInternalControl which ensures that the instance is private & can be initialized only in the constructor or at the point of declaration. We will re-look this in the IInternalControl interface discussion.
2. The class exposes some members which only give a call to the IInternalControl implementation
3. We have 2 constructors – a public, parameter-less implementation & an internal implementation which accepts the IInternalControl type parameter.

So, what really is the IInternalControl interface?

I have defined it like so:

The interesting pieces of this code are:

1. The interface is marked internal.
2. The interface defines all the publicly visible members of the InternalControl class & is implemented by the InternalControl class.

By implementing the interface, we are ensuring that the InternalControl class is responsible for implementing the items needed to work with the third party control.

In the MyApplicationControl class, we expose a private property of a type which implements the IInternalControl. By doing this, we are giving enormous flexibility to the MyApplicationControl class since now the class can contain instances of various types of controls which have the IInternalControl interface implemented.

For a good measure, we have expose the parameterized constructor of MyApplicationControl as internal so that we can derive from this control in the same namespace & pass the object of a completely new implementation to the base class.

Advantages of the solution:

By this implementation, we are exposing types which are under control within our application without adding the third party implementation directly into our source code.

If the HPC wishes to use another "oh-so-cool" control in place of the current third party implementation six months into development, the impact would be limited to the implementation in the InternalControl class or within the same namespace.

Alternatively, you can provide support to various flavors of Third Party implementations by interpreting the constructor of the MyApplicationControl class.

I find this extremely useful & would love to hear what you guys think.