[zasada] DIP - Dependency Inversion Principle / Zasada Odwracania Zależności

1. Moduły wysokopoziomowe nie powinny zależeć od modułów niskopoziomowych. Obie grupy modułów powinny zależeć od abstrakcji.

2. Abstrakcje nie powinny zależeć od szczegółowych rozwiązań. To szczegółowe rozwiązania powinny zależeć od abstrakcji.


O co w tym chodzi?
Posłużmy się przykładem. Każde użycie operatora new jest naruszeniem zasady DIP, lecz nie należy popadać w panikę. Wszystko trzeba robić z głową. Jeśli nasza klasa rzadko ulega zmianie, bądź przewidujemy, że nie będzie często się zmieniać, to nie powinniśmy mieć problemów wynikających ze złamania zasady DIP.
Stosowanie np. wzorca projektowego factory method , strategii, metody szablonowej powoduje odwrócenie zależności.
Skupmy się teraz na przykładzie:

    class B
    {
        public void ZrobCos() { }
    }

    class A
    {
        public void Metoda()
        {
            B b = new B();

            b.ZrobCos();
        }
    }

Jakakolwiek zmiana w klasie B może mieć wpływ na zachowanie klasy A. Poza tym, klasa A może tylko sterować zachowaniem B. Jak to zmienić? Oczywiście ABSTRAKCJĄ. Stosujemy w tym przypadku interface dla klasy B, popatrzmy:

  interface IB
    {
        void ZrobCos() { }
    }
    
    class B : IB
    {
        public void ZrobCos() { }
    }

    class A
    {
        public void Metoda()
        {
            IB b = new B();

            b.ZrobCos();
        }
    }

Co osiągnęliśmy?
-odwróciliśmy zależności (wyeliminowaliśmy zależność między abstrakcją a szczegółami implementacji)
-klasa A może sterować dowolnymi klasami implementującymi interface IB

Również zasada DIP przydaje się bardzo podczas tworzenia struktury projektu do wyeliminowania zależności między modułami.



Obrazek przedstawia jak bardzo moduł Presenter zależy od modułu Gateway. Poza tym każda nowa kompilacja Presentera wiąże się z ponowną kompilacją Gateway (powstaje nowe wydanie, a co za tym idzie trzeba puścić testy jednostkowe dla tych 2óch modułów). Stosując abstrakcję odwracamy zależność:



Teraz interface IGateway jest jakby "barierą" odgradzająca szczegółową implementację Gatewaya. Kompilacja Presentera w żadnym stopniu nie wpłynie na Gateway. Należy jeszcze dodać, iż IGateway również jest tutaj osobnym modułem, bądź znajduje się w module Presenter.