SOLID – akronim. Wymyślony przez Roberta C. Martina – wujka Boba. Zbiór dobrych praktyk.
S – Single Responsibility Principle (SRP). Pierwsza reguła. Brzmi:
“Każdy moduł powinien mieć jedną i tylko jedną przyczynę zmian.”
Reguła ta często jest źle interpretowana. Programiści zakładają, że moduł powinien wykonywać tylko jedno zadanie. Nie o to chodzi w tej regule.
Istnieje taka reguła, ale powinniśmy ją wykorzystywać, tworząc funkcje, ponieważ funkcja powinna wykonywać tylko jedno zadanie.
System zmieniany jest przez użytkowników – aktorów, czyli oni są przyczyną zmian. Ostateczna wersja reguły SRP:
“Każdy moduł powinien odpowiadać przed jednym i tylko jednym aktorem.”
Poniżej przykład:
Mamy tutaj trzech aktorów: księgowego, HR, administratora. Gdy chcemy być zgodni z regułą powinniśmy wynieść metody, należące do różnych aktorów do oddzielnych klas. Poniżej klasy wyniesione:
Mamy klasy, które zawierają metody należące tylko i wyłącznie do jednego aktora. A czy coś Ci nie pasuje w klasie SalaryManager?
Jeszcze jedna rzecz, ponieważ oprócz patrzenia na odpowiedzialności aktorów, dlatego musimy też patrzeć na różne poziomy abstrakcji metod.
Jeśli jedna metoda coś oblicza, a druga zajmuje się wyświetlaniem raportu, raczej nie współdzielą ze sobą wielu pól. Metody nie są zależne od siebie, ponieważ klasa cechuje się niską kohezją(poniżej definicja). Dlatego wpływając na jedną z metod, możemy zepsuć drugą mimo tego, że są niezależne od siebie. Warto więc to rozdzielić, ponieważ otrzymujemy wtedy klasy z wysoką kohezją.
Rozdzieliliśmy te metody do odrębnych klas, ponieważ SalaryCalculator oblicza i zapisuje na bazie. Natomiast SalaryReport zajmuje się przygotowaniem raportu. Dlatego jest tutaj wykorzystany wzorzec CQRS (oddzielenie zapisu od odczytu). To tylko przykład.
Główna zasada SOLID:
Każdy komponent powinien się charakteryzować wysoką kohezją i niskim couplingiem. Do tego dążymy.
Kohezja – sposób określania jak bardzo poszczególne elementy klasy pasują do siebie, jak bardzo są spójne ze sobą.
Uwaga! Możemy przyjąć, że reguła Single Responsibility jest spełniona, gdy klasa ma wysoką kohezję. Jest to prostsza definicja. Łatwiej mierzalna. SOLID SRP nie daje konkretów. Dlatego można na różne sposoby ją interpretować.
Wszystkie pola klasy (stan) są używane przez większość albo wszystkie metody – to znaczy, że klasa jest spójna – ma wysoka kohezję.
Niska kohezja jest, gdy klasa produktu oblicza jego cenę i ma metodę, która opisuje produkt. Cena nie ma nic wspólnego z opisem i odwrotnie, ponieważ taką klasę możemy podzielić. Podobne do przykładu wyżej z SalaryManager.
Coupling – służy do mierzenia powiązań i siły relacji między nimi. On zawsze musi występować, ale dążymy do jak najbardziej niskiego couplingu.
Kod w którym jest dużo zależności, ciężko testować. Ponieważ jedna zmiana, może spowodować wiele zmian w innych miejscach i dodatkowo może powodować błędy.
Jest wiele rodzajów couplingu, ale najważniejsze to: mocny i luźny coupling. Dlatego mocny coupling to taki, w którym moduły znają wewnętrzną implementację modułu, a luźny to ten, w którym moduły rozmawiają ze sobą za pomocą ustalonych interfejsów.
WAŻNE! Tutaj video pokazujące na prawdziwym przykładzie jak zachowywać tą regułę: link
Tutaj cała playlista, która jest rozszerzeniem tego video: link
Warto obejrzeć. Ponieważ mówi o tym jak podchodzić do tworzenia oprogramowania, jak tworzyć kod łatwo testowalny, jak tworzyć value objecty.
Jakub Pilimon jeden z twórców tej playlisty, twierdzi, że jeżeli ma się syf w projekcie, to warto zacząć od wprowadzania w nim value object’ów, ponieważ sprawią one, że kod stanie się już czytelniejszy.
Tutaj jeszcze raz link do playlisty: link
Sprawdź czy klasy, które implementujesz mają wysoką kohezję.
Źródło:
https://www.youtube.com/watch?v=WiK0-QIjvJw&list=PLhrnlSg3g_AQVGWbtVUIJBpLjrRk5X2YK&index=3
