Question

I had a discussion with friends last week about consuming the classes which are in DLL(.net DLL). I have a .net DLL which I need consume it in my Exe.

Normally,

1. I add the DLL in my solution and reference the DLL in my Exe
2. Create the object of the Class(which is in my DLL)
3. Start calling methods /function in the class from the object just created.

But finally decided that, We should use Reflection not the way we are doing. Reason is Loose coupling. One can change the functionality in the DLL and compile it. In such situations, You don’t need to compile client code.

I have a question with this background.

Suppose, I have an a very simple application(Say console application) and I have two classes both are writtern to do different work.

class Program
{
    static void Main()
    {

        //How do you create a object of the class A. 

    }
}


class A
{

    string A = "I am from A";
    public B b; 
    public A
    {
        b = new B();

    }
}

class B
{

    string B = "I am from B";
    public B
    {

    }
    public void Print()
    {
        Console.WriteLine(B);
    }
}      

How do you create the object of Class A when all the three classes the same exe and how you create the same object when Class A and class B in different DLL.

one answer for the sencond part of the question is use interface and use reflection.

Is reflection is it really required, or it is kind of programming standard.

What is the best practice to create an object of the class.

Answer 1

Interfaces provide a way to have loose coupling.

If you want to provide the ability to extend or replace the functionality after the fact without recompiling or even redeploying, then you’re basically looking at a plug-in type architecture on top of the interface based loose coupling.

You could either use reflection to iterate and create an instance of the object but the other option is configuration/registration. For example, in your config file (or registry etc…) you could point to the file and class that implements that interface and use System.Activator to create it at runtime.

Example:

http://msdn.microsoft.com/en-us/library/ms972962.aspx

Another more robust option is MEF. It’s a plug-in framework developed b the .net framework team.

Check out this link:

http://mef.codeplex.com/

From that link (reenforcing your question):

“Application requirements change frequently and software is constantly evolving. As a result, such applications often become monolithic making it difficult to add new functionality. The Managed Extensibility Framework (MEF) is a new library in .NET Framework 4 and Silverlight 4 that addresses this problem by simplifying the design of extensible applications and components. “

Hope that helps.