[IoC] Kontenery IoC

Kontenerem IoC można w skrócie nazwać pewien mechanizm wykonujący wstrzykiwanie zależności (Dependency Injection). Funkcjonalnością kontenera musi być możliwość konfiguracji zależności jakie zachodzą między obiektami. Kiedy prosimy kontener o typ podając mu na przykład interfejs, wie co ma nam zwrócić, a także wie jakie zależności powinien dany obiekt posiadać (czym różni się od wzorca ServiceLocatora).

Przykład zależności pomiędzy obiektami:

public class AudiA4
    {
        private readonly IEngine _engine;

        public AudiA4(IEngine engine)
        {
            _engine = engine;
        }

        public void Run()
        {
            _engine.Run();
        }
    }

    public interface IEngine
    {
        void Run();
    }

    public class DieselEngine : IEngine
    {
        public void Run()
        {
            Console.Write("Diesel engine running...");
        }
    }

Kontener tworzą dwie metody. Pierwsza pozwala na rejestrowanie typów w słowniku. Typy rejestrowane powinny być po interfejsach tylko wtedy jeżeli implementujemy dany interfejs więcej niż raz. W przeciwnym wypadku tworzymy niepotrzebne byty. Druga metoda tworzy obiekt na podstawie wcześniej skonfigurowanych zależności. W C# możemy skorzystać z mechanizmu Reflection, przez co zajmuje nam to bardzo mało kodu. Ponieważ w bardziej rozbudowany aplikacjach możemy mieć wielopoziomowe grafy obiektów, metodę Resolve wołamy rekurencyjnie, aby rozwiązać wszystkie zależności.

public class IocContainer
{
    private Dictionary<Type, Type> dependencyMap;

    public IocContainer()
    {
        dependencyMap = new Dictionary<Type, Type>();
    }

    public T Resolve<T>()
    {
        return (T) Resolve(typeof(T));
    }

    private object Resolve(Type type)
    {
        Type resolvedType = null;
        try
        {
            resolvedType = dependencyMap[type];
        }
        catch
        {
            throw new KeyNotFoundException(String.Format("Cannot resolve type {0}", type.FullName));
        }
        var ctor = resolvedType.GetConstructors().First();
        var parameters = ctor.GetParameters();
        if (parameters.Count() == 0)
            return Activator.CreateInstance(resolvedType);
        IList<object> @params = new List<object>();
        foreach (var parameter in parameters)
        {
            @params.Add(Resolve(parameter.ParameterType));
        }
        return ctor.Invoke(@params.ToArray());
    }

    public void Register<TFrom, TTo>()
    {
        dependencyMap.Add(typeof(TFrom), typeof(TTo));
    }
}

Przykład użycia kontenera:

static void Main(string[] args)
{
    var container = new IocContainer();
    container.Register<AudiA4, AudiA4>();
    //zależnie od konfiguracji
    container.Register<IEngine, DieselEngine>();
    var car = container.Resolve<AudiA4>();
    car.Run();
}

[SOLID] DIP: Inversion of Control, Dependency Injection

SOLID to akronim reprezentujący 5 zasad programowania obiektowego. Ostatnia litera D pochodzi od zasady odwrócenia zależności (Dependency Inversion Principle - DIP).

Problem zależności w kodzie dotyczy na przykład sytuacji jak poniżej:

public class AudiA4
{
 public void Run()
 {
  //zależność
  var engine = new GasEngine();
  engine.Run();
 }
}

Zasada odwrócenia zależności głosi, że:
Moduły wysokiego poziomu nie powinny zależeć od modułów niskiego poziomu. Jedne i drugie powinny być zależne od pewnych abstrakcji. 
Abstrakcje same w sobie także nie powinny zależeć od szczegółów. Dzięki temu dodawanie nowych komponentów lub ich wymiana nie będzie powodować zmian w modułach wysokiego poziomu.

Sposobem na zastosowanie tej zasady jest "wzorzec" Inversion of Control. Cudzysłów bierze się stąd, że IoC definiowane jest na stosunkowo wysokim poziomie abstrakcji w porównaniu z innymi wzorcami. Możemy go zastosować do różnego rodzaju kontroli:

• flow aplikacji
• sterowanie pomiędzy systemami za pomocą wspólnego interfejsu
• tworzenie i binding zależności w programie

Sposobem implementacji IoC jest wstrzykiwanie zależności (Dependency Injection - DI).

Flow aplikacji - przykładem na odwrócenie zależności jest zastosowanie graficznego interfejsu użytkownika. W starych aplikacjach konsolowych, program pyta użytkownika o konkretną daną, oczekuje na odpowiedź i wykonuje się dalej. Po odwróceniu zależności, użytkowik z GUI dostarcza do programu te informacje, które akurat chce dostarczyć. Następuje zatem przejście od kodu proceduralnego do programu będącego reakcjami na zdarzenia użytkownika. Wszystko zgodnie z zasadą "Don't call us, we will call you".

Interface Inversion - przyjmując,  że aplikacja składa się z providerów usług i ich konsumentów, możemy zauważyć, że tradycyjnie to konsument zależy od providerów. Po odwróceniu zależności to konsument, poprzez pewien interfejs decyduje o tym, czego potrzebuje od providerów. Konsument posiada zatem referencję do pewnego interfejsu, który implementują providerzy, sam nie musi się do niczego dostosowywać.

Tworzenie i binding obiektów - polega na tym, aby tworzyć obiekty niskiego poziomu poza obiektami wysokiego poziomu.

Pewnym typem IoC jest Dependency Injection. Cały problem polega na tym, że skoro nie chcemy tworzyć obiektów niskiego poziomu w obiektach wysokiego poziomu, to jakiś mechanizm musi nam je wstrzykiwać. Mamy zatem do dyspozycji trzy podstawowe pomysły na wstrzykiwanie zależności:

• przez konstruktor - wymusza wstrzykiwanie przy tworzeniu obiektu

IEngine gasEngine = new GasEngine();
AudiA4 car = new AudiA4(gasEngine);

public class AudiA4
{
 private readonly _engine;

 public AudiA4(IEngine engine)
 {
  _engine = engine;
 }

 public void Run()
 {
  _engine.Run();
 }
}

• przez setter - dzięki temu podejściu można korzystać z klasy przed wstrzyknięciem zależności, w C# można korzystać bezpośrednio z properties, w innych językach trzeba posiłkować się funkcjami.

AudiA4 car = new AudiA4();
car.Engine = new GasEngine();

public class AudiA4
{
 public IEngine Engine { get; set; }

 public void Run()
 {
  Engine.Run();
 }
}

• przez interfejs - jawnie pokazujemy, że do danej klasy wstrzykiwane będą zależności. 

AudiA4 car = new AudiA4();
var engine = new GasEngine();
((IDependsOnEngine)car).Inject(engine);

public class AudiA4 : IDependsOnEngine
{
 private IEngine _engine;

 public void Run()
 {
  _engine.Run();
 }

 public void Inject(IEngine engine)
 {
  _engine = engine;
 }
}

public interface IDependsOnEngine
{
 void Inject(IEngine engine);
}

Dependency Injection jest genialnym mechanizmem, jednak warto pamiętać o kilku jego wadach, aby nie nadużywać go, gdy nie jest potrzebny. Przede wszystkim narusza zasadę enkapsulacji - silnik wyciągany jest poza obiekt samochodu. Często także zależności tworzymy wcześniej niż ich potrzebujemy, bo na przykład zmusza nas do tego konstruktor. Nadużywanie DI może także doprowadzić do sytuacji, gdy klasa implementuje kilkanaście interfejsów, co także nie jest raczej wskazane.