Seria artykułów jest moją interpretacją zasad SOLID.

SOLID -Skrót wyprodukowany przez Roberta C. Martin-a (zw. onkel Bob)

Pod tą nazwą kryje się zbiór „dobrych praktyk”, które ułatwiają tworzenie kodu i późniejsze rozwijanie go.

Ja na początku 2018 roku przeszedłem z teorii do praktyki i po roku praktykowania muszę stwierdzić, że zmiana przynosi pewne efekty. Jeżeli ktoś myśli że może nauczyć się solida w tydzień, to ma racje, nawet w jeden dzień. Tylko między nauką i praktyką w tym kontekście jest zasadnicza różnica. Ja po roku używania solid-a nie jestem przekonany, że w pełni umiem go wykorzystać i wydaje mi się, że jeszcze kilka lat minie za nim w całości go zrozumie.

Solid:

  • S – Zasada pojedynczej odpowiedzialności,
  • O – Zasada otwarty-zamknięty,
  • L – Podstawienie Liskov,
  • I – Segregacji Interfejsów,
  • D – Odwrócenie zależności

Czy SOLID jest lekarstwem na wszystkie „bóle” programowania? 

(TAK/Nie) niepotrzebne skreślić.

SOLID to jest tylko zestaw dobrych praktyk, które możesz stosować, a nie musisz (powinieneś/nie powinieneś) . Tam nie ma napisane zrób to i to, a będzie dobrze, tam jest przedstawiona pewna idea dzięki której, być może się uda, bo jak każdy wie nawet najlepsze rozwiązania można spier#####.

Postanowiłem się skupić nad Dependency Inversion, a dokładnie nad zastosowaniem tego w praktyce czyli na Dpendency Injection – wstrzykiwaniem zależności.

Czym jest jest Dependency Inversion? Jest pozbyciem się zależności od obiektów innych klas na rzecz dodatkowej abstrakcji, która „łączy” klasy.

Czym jest Dependency Injection? jest wstrzyknięciem w kod tychże zależności poprzez konstruktor, parametr metody, właściwość klasy.

Abstrakcja?, częściej interfejs , rzadziej klasa abstrakcyjna.

Przykładowy kod będę prezentował w oparciu o kod aplikacji obsługującej Maraton Rowerowy (standardowo).

Dependency Inversion – poprzez interface

Na początku uwaga, w interfejsie nie można deklarować zmiennych, a jedynie metody get i set do tej zmiennej. Czy akurat w tym kodzie są potrzebne? w tym kontekście nie ma to znaczenia.

Dependency Injection – z użyciem interfejsu

  1. Poprzez konstruktor ,
  2. Poprzez parameter metody,
  3. Poprzez właściwość klasy

1. Poprzez konstruktor

Wyjaśnienie kodu:

Klasa SimpleAddingParticipant służy do uproszczonego dodania nowego zawodnika, minimalna wymagana ilość informacji tj imię, nazwisko, email i dystans. W bazie ustawiona jest unikalność na imię, nazwisko i email.

Klasa SimpleAddingParticipant wykorzystuję metody z trzech interfejsów:

  • INewRecord – metoda createNewRecord – tworzy nowy obiekt klasy Kartoteka2,
  • IAddZawodnik – metoda addParticipantWithoutTimeRegistrationVerification – wywołuje procedure składowaną, która dodaje nowego zawodnika,
  • IPlayerVerification – metoda searchPlayer – wyszukuje czy dany zawodnik jest już zarejestrowany (zapisany w bazie),
  • metoda validateFormatEmail – sprawdza formę zapisu adresu email

Deklaracja interfejsu:

Klasa zakontraktowana (dziedzicząca interfejs)

Jeszcze wywołanie w kodzie tutaj fragment kontrolera

Testy do powyższego kodu znajdują się w innym moim poście Testy SimpleAddingParticipant

Tu należy się jeszcze krótkie sprostowanie w projekcie jest kontener zależności, który rozwiązuje zależności pomiędzy interfejsami  INewRecord, IAddZawodnik, IPlayerVerfication a ich klasami.

Wstrzyknięcie poprzez parametr metody druga część posta.

Dependency Injection: Constructor vs Property