Blog
Blog HelionBlog HelionBlog HelionBlog Helion
  • Artykuły
  • Autorzy
  • Recenzje
  • Konkursy

Mnemonik SOLID – D jak Dependency Inversion Principle

    Blog.helion.pl Artykuły Mnemonik SOLID – D jak Dependency Inversion Principle
    NastępnyPoprzedni

    Mnemonik SOLID – D jak Dependency Inversion Principle

    By Jerzy Piechowiak | Artykuły, Programowanie | Brak komentarzy | 13 października, 2016 | 0

    Przyszła pora na ostatnią literkę z mnemonika SOLID, ale to wcale nie oznacza, że jest ona najmniej ważna. D rozwijane jest jako Dependency Inversion Principle co tłumaczone jest jako Zasada Odwrócenia Zależności. Nazwa brzmi odrobinę tajemniczo, ale tak naprawdę opisuje ona dwie istotne reguły:

    1. Moduły wysokiego poziomu nie powinny zależeć od modułów niskiego poziomu.
    2. Abstrakcje nie powinny zależeć od szczegółów (konkretnej implementacji). Z kolei szczegóły (implementacja) powinny zależeć od abstrakcji.

    Obie reguły brzmią w chwili obecnej odrobinę tajemniczo, ale jak zobaczycie w dalszej części tekstu, niosą one ze sobą głębszy sens.

     

    Dependency Inversion Principle

    Z pewnością niejednokrotnie programując, zdarzyło Wam się wygenerować kod, który posiadał sztywne powiązania. Np. utworzyliście klasę zależną do klasy głównej, ale jednocześnie nie wyprowadziliście interfejsu klasy podrzędnej. Typowy problem każdego programisty, który wraz ze wzrostem doświadczenia zdarza się coraz rzadziej. Okazuje się jednak, że samo stworzenie interfejsu czasem nie wystarczy by można było odtrąbić sukces. Niezwykle ważne bywa również miejsce, w którym się go tworzy oraz szersza perspektywa.

     

    Tworząc interfejs powinniśmy myśleć przede wszystkim o klasie głównej, która będzie go konsumowała, a nie o klasie szczegółu, która będzie go implementowała.

    Trzymając się standardowej nomenklatury dla tego przypadku, wyjściowo mamy klasy:

    – Foo

    – Bar

    – Bar jest elementem podrzędnym dla Foo

     

    Już na pierwszy rzut oka widoczne jest sztywne powiązanie pomiędzy klasami. Naturalnym krokiem będzie wydzielenie interfejsu IBar. W tym miejscu jednak powinniśmy pamiętać, by przede wszystkim zaspokajał on potrzeby klasy Foo, a dopiero później potrzeby klasy Bar, którą trzeba by ewentualnie dostosować do nowych realiów:

    – Foo

    – IBar

    – Bar

    – Foo wykorzystuje interfejs IBar, Bar implementuje interfejs IBar

     

    Można to schematycznie przedstawić za pomocą diagramu, na którym widać wyraźny podział pomiędzy elementami, w którym to klasa Foo i interfejs IBar trzymają się razem, natomiast klasa szczegółów Bar, znajduje się gdzieś „na uboczu”.

    Przekładając to na biblioteki, bardzo często będzie tak, że klasa Foo oraz interfejs IBar znajdą się w jednej z bibliotek, natomiast konkretna implementacja pojawi się w innym miejscu. Za pomocą kontenera IoC dokonamy wiązania interfejsu oraz konkretnej implementacji klasy szczegółu w miejscu wdrożenia.

     

    Przykład praktyczny

    W przykładzie praktycznym skorzystam raz jeszcze z kodu generatora raportów. Przypomnijmy sobie najpierw strukturę klasy ReportGenerator, którą możemy uznać za główną w naszym obecnym przypadku:

     
    public class ReportGenerator
    {
        public void GenerateReport(IFileWriter fileWriter, DateTime date)
        {
            IDatabaseManager databaseManager = new MyDatabaseManager();
            var reportData = databaseManager.GetReportData(date);
    
            fileWriter.Open();
            fileWriter.WriteData(reportData);
            fileWriter.Close();
        }
    }
    

    Wcześniej pomyślałem już o odpowiednich interfejsach, dlatego część problemu mamy z głowy. Raz jeszcze musimy pamiętać teraz, by odwrócić zależności tj. interfejsy powinny być przede wszystkim ważne z perspektywy potrzeb klasy ReportGenerator, a nie z perspektywy klas, które implementują interfejsy IDatabaseManager oraz IFileWriter. Bardzo dobrym posunięciem byłoby w tym przypadku nawet, przesunięcie klas implementacyjnych do osobnych bibliotek (tego oczywiście nie będzie widać na listingu, ale pozostawiam to Waszej wyobraźni:-). Taki krok pozwoliłby na lepsze pogłębienie zasady Dependency Inversion Principle i jednocześnie przyczyniłby się do zwiększenia użyteczności biblioteki bazowej. Jeśli kiedykolwiek wykorzystywaliście biblioteki portable (a teraz również .Net Core) to szybko przekonacie się, że im mniej kodu, w tak kluczowych miejscach tym lepiej. Trudniej w takiej sytuacji natknąć na kod specyficzny dla danej platformy.

     

    Na koniec przypomnę również definicję wymienionych wyżej interfejsów:

     
    public interface IFileWriter
    {
    	void Open();
    	void WriteData(IEnumerable<string> data);
    	void Close();
    }
    
    
    public interface IDatabaseManager
    {
    	IEnumerable<string> GetReportData(DateTime date);
    }
    

    Jerzy Piechowiak

    Altcontroldelete.pl

     

     Szukasz książki do C#? Kliknij TU lub zerknij poniżej:

              

     

    c#, Jerzy Piechowiak, mnemonik solid, programowanie, SOLID
    Avatar

    Jerzy Piechowiak

    Więcej postów od Jerzy Piechowiak

    Podobne posty

    • Wzorzec projektowy strategii

      By Jerzy Piechowiak | Brak komentarzy

      Programowanie, wbrew obiegowym opiniom, nie jest aż takie trudne. Wypuszczenie nawet prostych aplikacji mobilnych czy stron nie wymaga dzisiaj dużych nakładów sił. Największym problemem jest napisanie takiego kodu, który będzie łatwo rozszerzalny i będzie miałCzytaj więcej…

    • Wzorce projektowe — null object

      By Jerzy Piechowiak | Brak komentarzy

      „Object reference not set to an instance of an object” — taki, pojawiający się w najmniej oczekiwanym momencie komunikat to zmora każdego programisty C#. Przyczyna jest zawsze taka sama, a jest nią wyjątek NullReferenceException.

    • Mnemonik SOLID – I jak Interface segregation principle

      By Jerzy Piechowiak | 1 komentarz

      W poprzednich wpisach poświęconych SOLID, niejednokrotnie pojawiały się wzmianki o interfejsach. Osobiście jestem ich gorącym zwolennikiem, ale wszystkiego trzeba używać z głową. Tego nauczy Was życie.. i w tym przypadku właśnie czwarta zasada z mnemonikuCzytaj więcej…

    • Mnemonik SOLID — L jak Liskov Substitution Principle

      By Helion | Brak komentarzy

      Liskov Substitution Principle to prawdopodobnie jedna z najbardziej pokręconych zasad mnemonika SOLID. Po raz pierwszy została sformułowana przez Barbarę Liskov w 1987 roku (za Wikipedią), stąd też jej nazwa. W polskim tłumaczeniu nazywamy ją zasadą podstawieniaCzytaj więcej…

    • Mnemonik SOLID — O jak Open/Closed Principle

      By Helion | Brak komentarzy

        Tworząc oprogramowanie, bardzo często stoimy przed dylematem: czy pisać kod szybko, czy porządnie. Oczywiście, o ile tylko mamy możliwość, wybierajmy tę drugą opcję, jednak taka decyzja generuje nowy problem, ponieważ na wczesnym etapie procesuCzytaj więcej…

    NastępnyPoprzedni

    Znajdź post

    Bądźmy w kontakcie

    Książka dnia

    Wszechstronny JavaScript. Technologie: GraphQL, React, React Native i Electron

    Autor: Adam D. Scott

    Cena: 34.50 zł 69.00 zł
    (Cena e-booka: 34.50 zł 69.00 zł)

    O 35zł taniej!

    kup teraz

    Ostatnie wpisy

    • Błyskawiczny kurs pisania skryptów powłoki
    • Przykładowa aplikacja webowa zaimplementowana w ASP .NET Core
    • Wprowadzenie do .NET Core: instalacja, konfiguracja, pierwsza aplikacja w systemie Linux
    • Grupa Helion zaprasza na szkolenia stacjonarne!
    • Hello World! Czym jest programowanie?

    Tagi

    .net agile altcontroldelete asp.net c# czysty kod debugowanie design patterns e-biznes emarketing Google Google Analytics hacking Jerzy Piechowiak kod kodowanie Krzysztof Marzec książka Maciej Dutko magazyn programista Magdalena Daniłoś marketing MVVM onepress organizacja czasu praca prograista programista programowanie prokrastynacja rafał kocisz reklama rozwój software craftsman SOLID startup techniki programowania testowanie video marketing visual studio WPF wzorce projektowe youtube zarządzanie czasem zarządzanie projektami

    Archiwum

    • lipiec 2017
    • czerwiec 2017
    • maj 2017
    • kwiecień 2017
    • marzec 2017
    • luty 2017
    • styczeń 2017
    • grudzień 2016
    • listopad 2016
    • październik 2016
    • wrzesień 2016
    • lipiec 2016
    • czerwiec 2016
    Blog wydawnictwa
    Informatyka w najlepszym wydaniu
    Strona wydawcy:
    www.helion.pl
    Księgarnia Helion.pl
    Nowości
    Bestsellery
    Promocje
    Bądźmy w kontakcie:
    Chcesz zostać autorem?
    Masz pytania do redakcji?
    Napisz do nas »
    • Artykuły
    • Autorzy
    • Recenzje
    • Konkursy
    Blog Helion