W sobotę odbyła się łódzka konferencja GET.NET (o czym jeszcze napiszę), w trakcie której tuż przed moją, odbyła się prezentacja Procenta o Dependency Injection. Samo wystąpienie było świetne, a moją ciekawość podsyciła dodatkowo obietnica (powtórzona dwukrotnie) wyjaśnienia całego zamieszania wokół pojęć DI (Dependency Injecton i Inversion) oraz IoC. Jakie było moje rozczarowanie, gdy upragniony moment nadszedł, a Maciek skwitował wszystko zdaniem, że definicje nie są ważne.

Oj wkurzyłam się… Pomyślałam – naprawdę? Czy to, że ludzie mylą te pojęcia oznacza, że powinniśmy to olać i pozwolić, by żółć sączyła się z rany? Oczywiście zgadzam się z ogólnym stwierdzeniem, że w sumie nie ważna jest nomenklatura, byle dobre praktyki stosować, ale… czy na pewno tak jest do końca? Czy SRP pod inna nazwą równie by pachniała? Czy od teraz powinniśmy się komunikować opisując co dana zasada czy wzorzec robi, zamiast operować ich nazwami? Jakoś tego nie widzę, zajmowałoby to stanowczo za dużo czasu.

No to jak to jest z tym IoC i DI? Ano bardzo prosto, aż szkoda, że tyle przekłamań w internetach. Zacznijmy od ogółu.

Inversion of Control

IoC jest zasadą, która przeciwstawia się tradycyjnemu proceduralnemu podejściu do programowania. Polega na odwróceniu kontroli (tak, wiem, że rozumiecie ), w taki sposób, by miał ją zewnętrzny kod zamiast głównego flowu.

A oto obrazek przedstawiający ideę, zapożyczony z ok kolegi z fb, gdyż stwierdził (a ja się zgodziłam), że go tu brakuje.

W tradycyjnym podejściu nasz program wykonuje kroki, wywołując metody bibliotek, do których posiada on referencje. W podejściu IoC natomiast, to zewnętrzny software wywołuje nasz kod by wykonać pewne akcje. Relacje wtedy układają się zupełnie na odwrót. Dlatego zasada ta jest często żartobliwie nazywana regułą Hollywood: Don’t call us, we’ll call you.

Jest to więc bardzo szerokie pojęcie, dużo szersze niż wstrzykiwanie zależności, czy Service Locator. Przykładami z innej bajki są eventy, callbacki, czy zwykłe programowanie bazujące na interfejsach (np. wzorzec strategii).

Dependency Injection

Czyli wiemy już, że DI jest po prostu jedną z implementacji IoC. Wzorcem projektowym polegającym na tym, że przekazujemy (injection) zależność (dependency) do obiektu. Zależność staje się częścią stanu klienta (np. polem klasy lub jego property). Kluczową sprawą jest fakt jej przekazania, by nie pozwalać na tworzenie lub pozyskiwanie jej po stronie używającego obiektu.

Dependency Inversion

A jak się ma do tego Dependency Inversion? Jest to jedna z zasad SOLID faworyzująca taką budowę modułów, by odwrócić zależności i wprowadzić jak najbardziej luźne powiązania między nimi. DI oraz Service Locator się do niej stosują. A brzmi ona następująco:

• Moduły wyższego poziomu nie powinny polegać na modułach niższego poziomu, lecz na abstrakcjach
• Abstrakcje nie powinny polegać na konkretnych implementacjach, to konkretne implementacje powinny polegać na abstrakcjach

(Błędnie stosowana często prowadzi do tego, że po prostu wrzucamy na każdym poziomie interfejs, który jest implementowany przez dokładnie jeden moduł, ale to temat na zupełnie inny post.)

Mylić więc Dependency Injection i Dependency Inversion to całkiem normalna sprawa. Natomiast wrzucanie tego do jednego wora z IoC, to już lekkie nadużycie, bo wór ten jest o wiele obszerniejszy.

Jeśli zdarza się nam pracować z plikami .xaml i korzystamy z dobrobytu jakim jest bindowanie kod-widok (niezależnie od tego czy będzie to MVVM czy code behind), po pewnym czasie nadchodzi moment, gdy szlag nas trafia i musimy napisać po raz kolejny zamiast prostego ładnego property:

public class MyClass
{
    public string MyProperty { get; set; }
}

jakiegoś takiego potworka:

public class MyClass
{
    public event PropertyChangedEventHandler PropertyChanged;

    string _myProperty;
    public string MyProperty
    {
        get { return _myProperty; }
        set 
        {
            if (value != _myProperty)
            {
                _myProperty = value;
                OnPropertyChanged("MyProperty");
            }
        }
    }

    public virtual void OnPropertyChanged(string propertyName)
    {
        var propertyChanged = PropertyChanged;
        if(propertyChanged != null)
        {
            propertyChanged(this, new PropertyChangedEventArgs(propertyName));
        }
    }
}

Pojawiają się w naszej klasie: event, implementacja metody OnPropertyChanged, oraz jej wykorzystanie w setterach. Pomijam tu “smaczek” podawania nazwy w stringu. To i tak nie jest najgorsze co się nam może przydarzyć. Moglibyśmy mieć property, które odwołuje się do kilku innych. Wtedy musimy dodatkowo pamiętać, by OnPropertyChanged dla niego wykonać w setterach składowych.

Bleh…

Z pomocą przychodzi np. Fody. Jest to prosty pakiet, który należy ściągnąć (np. stąd, lub nugetem), zainstalować i nakazać projektowi, by go używał (Project > Fody > Enable). Dodatkowo, przyda się konfiguracja weavera. Jest na to kilka opcji, a tu już odsyłam do dokumentacji.

Ja akurat używam pliku .xml:

<?xml version="1.0" encoding="utf-8" ?>
<Weavers>
  <PropertyChanged EventInvokerNames="raisePropertyChanged"/>
</Weavers>

Dzięki temu nie muszę w swojej klasie ani w moim property robić nic poza czystym get i set. Moje ViewModele stają się zwykłymi klasami, bo chyba do tego zostały wymyślone.

Fody oczywiście sporo od siebie dodaje i kod przybiera inną formę. Nasza klasa zaczyna implementować interfejs, dostaje event, ma zaimplementowaną metodę OnPropertyChanged, a wszystkie property są poorane w przedstawiony wcześniej sposób, nawet te złożone z kilku innych. Ale czego oczy nie widzą, tego sercu nie żal