Building Pipeline Infra into Microsoft based designs - Part I

Today I going to take up one of the topics I mentioned in my earlier blog i.e. "Building Pipeline Infra into Microsoft 
based designs". I chose this topic because this is going to be one of the building blocks of my future topics. There will be 2 parts of this topic ".NET" part and "Pipeline Design" part.

.NET Part

Before starting I would like to go back to some .NET basics. If you do not have these concepts then this is going to help you.

In almost all the interviews you have attended in Java or .NET you have been asked about this - Interfaces and Abstract classes.
In most of my encounters with colleagues and other acquaintances and in interviews, no one was able to answer the real use of interfaces and abstract classes when asked. 

Can you ? I always ask this:What is the difference between an "interface" and an "abstract class". The answer that I usually get is "Interface can contain only method definition while abstract classes can contain method implementation too". 

Correct ! But my next question usually bowls them out. "What is the difference between an interface an "abstract class with all abstract methods" ? Why has Microsoft provided us with a separate construct which can act as a contract ?"

The answer lies in OOPS concepts "Principle of substituality" and "Late or Dynamic Binding". 


public class A
{
public A(){}
public string Display(){ return "A";}
}
public class B : A
{
public B(){}
public string Display(){ return "B";}
}

A objB = new B();

Moral of the above is that a parent or base class reference can contain child or derived class instance of an object.

[But there are different scenarios where a reference, as mentioned above, calls a method which exists both in parent and child class - which method is actually called ? Thats another topic to discuss which will be taken up in another blog.]

Lets now come to "interface".

Taking moral from above, we can also define as below.

Example:

public interface IData
{
int GetValue();
}

//classes implementing the above interface
public class MyData1: IData
{
public int GetValue()
{
return "1";
}
}

public class MyData2: IData
{
public int GetValue()
{
return "2";
}
}


//calling
IData o1 = (IData)(new MyData1());
IData o2 = (IData)(new MyData2());

o1.GetValue();
o2.GetValue();

The output of the above 2 statements is quite predictable i.e. 1 and 2. How is this concept helpful ?
This concept is helpful is various ways 
1) to make a design "Pipelined" 
2) make it extendible 
3) Make a design contextual

[The scenarios serving these will be discussed in next part of this topic].

How does this simple concept which you think you knew makes up for all the designs mentioned above ?
The answer lies in "Reflection" and concept of contract.

Say you have an interface I1 which is exposed by you in your product sdk. By exposing this interface publicly you are giving the developer (who is using your product and sdk) a way to implement his own logic in your product's processing "pipeline" [Pipeline programming]. Now there will be certain "hook" points exposed by you [and known to developer] in your product pipeline. 

Think of the product pipeline as a simple pipe or tube with holes at certain points along its length. You will be able to insert you own logic into this processing pipeline.

Now say the developer has written a class C1 implementing you interface I1. Since the class is bound by the I1's contract, it will for sure have all methods defined in I1. Now your task is to execute the logic implemented in the C1 class at the hook points in the pipeline. 

The process is simple, say one of the methods defined in I1 is "void Execute(object context);"

then...

I1 objC1 = (I1)(new C1());
objC1.Execute(null);

When you call "objC1.Execute(null)" [for now consider the context as null], the code written in Execute methodof C1 is executed. In this way you actually injected the custom developer logic in your product's processing pipeline.

Now there must be a question in you mind. How the hell do I get hold of this developer's class and where do I find it? This is where "Reflection" comes to our rescue.

Say the developer has written a class implementing your interface and built an assembly. nad you have registered this assembly in GAC or uploaded it in a database as a file blob. 
Then you have to dothe following:

1)Load this assembly in your executing pipeline
2)Get hold of the class implementing your interface.
3)Instantiate the class and get the object. Store it in interface reference.
4)Call the method.

Code:

//Load Assembly [e.g. from GAC]
Assembly asm = Assembly.Load("TestLib,Version=1.0.0.0, Culture=neutral, PublicKeyToken=421348bbd2628966");

//Get the types or classes in assembly implementing your interface
var type = typeof(I1);
Type[] types = asm.GetTypes();
List interfacetypes = new List();
foreach (Type p in types)
{
if (type.IsAssignableFrom(p))
        interfacetypes.Add(p);                
}

//Instantiate the class object
I1 objC1 = null;
if(interfacetypes.Count > 0)
objC1 = (I1)asm.CreateInstance(interfacetypes.ToArray()[0].FullName);

//Call the method
if(null != objC1)
objC1.Execute(null);


If you have any clarifications email me at purbarag@gmail.com