Simple dependency Injector class

It is apparent in todays application development that complexity starts from when we typed the first line of code. Code complexity is one of the code horrors mutilating todays application development. To ensure that we work around these developments show stoppers, many design patterns and software development standards have been built to help come over this poor development approach.

Today we develop software with components in mind, we develop so that we can easily decouple our systems and make it a pluggable system.

Systems are very difficult to decouple when we do not use a strategic and standardized ways of separating component concerns. Over the years, the development and Object Oriented community have realized that there was a need to separate application concerns because of changing business cases and requirements.

As a software developer i have made it a culture to think of software as several functional modules that are independent from one and other but dependent on one and other via a plugable means.

The following code shows an example of code coupling :

public class Person
{
public string FirstName { get; set; }
public string LastName { get; set; }
}

Person person = new Person();

There is nothing wrong with the code above really for a simple application. But for a very complex application, we tend to tight couple the Person class with the calling application. Let us assume the person class was imported from a web service proxy, that means our application is relying on the web service proxy for the Person Implementation. What then happens when we are not interested in web service proxy again but in another .dll that has its own Person implementation but with some extra fields and properties, do we start to refactor our code to comply with the new Person class? I bet that is not the easiest way ever.

Let us assume that person class now implements an interface IPerson. The following code depicts the kind of defination :

interface IPerson
{
string FirstName { get; set; }
string LastName { get; set; }
}

public class Person : IPerson
{
public string FirstName { get; set; }
public string LastName { get; set; }
}

Hmm, now that person have implemented an interface IPerson, then we could refer to IPerson all over our code, this is fairly decoupled until the very point where we really initialised the Person class, like the following :

IPerson person = new Person();

person.FirstName = "Ahmed";
person.LastName = "Salako";

now although we ahve succesfully initialised the Person class and because it implements the IPerson interface, we can assign it to the IPerson interface. Our code is still exposed to the point where we did new Person.


A simple Dependency Injector class

The following class will serve as a repository that knows about dependencies of our application :

public static class ModelFactory
{
private static IDictionary <Type, Type> repos = new Dictionary <Type, Type>();

static ModelFactory()
{
repos.Add(typeof(IPerson), typeof(Person));
}

public static T CreateInstance < T>()
{
Type value = repos[typeof(T)] as Type;
return (T)Activator.CreateInstance(value);
}

public static T AsInterface < T>(Type type)
{
Type value = repos.Where(t => t.Value == type).FirstOrDefault().Key;

return (T)Activator.CreateInstance(value);
}
}

So with the class above, we have successfully created a dependency repository class that knows about an interface and its implementations. Here is how to use the simple dependency repository class :

IPerson person = ModelFactory.CreateInstance < IPerson>();
person.FirstName = "Ahmed";
person.LastName = "Salako";

This leaves us very happy and with code decoupling.