(ang. Strategy)
To wzorzec behawioralny stosowany, gdy chcemy wykonać jakieś zadanie wybierając spośród różnych metod tą najbardziej odpowiednią w danej chwili.
Wzorzec ten daje również możliwość oddzielania logiki biznesowej od szczegółów implementacji poszczególnych algorytmów.
Wzorzec Strategia Czytaj więcej »
(ang. Factory)
Ten wzorzec kreacyjny wykorzystujemy do ułatwienia tworzenia nowych obiektów. Używając go, oddelegowujemy tworzenie nowych obiektów do innych klas tak, by użytkownik musiał wywołać tylko jedną metodę i otrzymał gotowy obiekt.
Możemy zastosować dwa podejścia: metoda fabrykująca i fabryka abstrakcyjna.
Wzorzec Fabryka Czytaj więcej »
(ang. Builder)
Jest popularnym wzorcem kreacyjnym. Buildera najczęściej używamy, gdy dana klasa ma bardzo dużo pól i nie chcemy dla niej tworzyć dużej liczby konstruktorów. Daje możliwość tworzenia złożonych obiektów etapami, krok po kroku.
Wzorzec Budowniczy Czytaj więcej »
(ang. Design Patterns)
Wzorce projektowe to uniwersalne, sprawdzone w praktyce rozwiązania często pojawiających się, powtarzalnych problemów projektowych. Pokazują powiązania i zależności pomiędzy klasami oraz obiektami i ułatwiają tworzenie, modyfikację oraz utrzymanie kodu źródłowego. Są one opisem rozwiązania, a nie jego implementacją.
Wzorce projektowe stosowane są w projektach wykorzystujących programowanie obiektowe.
Wzorce projektowe Czytaj więcej »
(Zasada odwracania zależności)
1. Moduły wysokiego poziomu nie powinny zależeć od modułów niskiego poziomu. Oba powinny zależeć od abstrakcji (np. interfejsów lub klas abstrakcyjnych).
2. Abstrakcje nie powinny zależeć od szczegółów. Szczegóły (konkretne implementacje) powinny zależeć od abstrakcji.
– Robert C.Martin (Uncle Bob)
Dependency Inversion Principle Czytaj więcej »
(Zasada segregacji interfejsów)
Klienci nie powinni być zmuszani do korzystania z interfejsów (zależenia od interfejsów), których nie używają.
– Robert C.Martin (Uncle Bob)
Interface Segregation Principle Czytaj więcej »
(Zasada podstawienia Liskov)
Jeżeli klasa S (podtyp) jest dzieckiem klasy T (typ), wówczas obiekty typu T można zastąpić obiektami typu S bez zakłócania działania programu.
– Barbara Liskov
Liskov Substitution Principle Czytaj więcej »
(Zasada otwarte zamknięte)
Jednostki oprogramowania (klasy, moduły, funkcje itp.) powinny być otwarte na rozszerzanie, ale zamknięte na modyfikacje.
– Meyer Bertrand
Open Close Principle Czytaj więcej »
(Zasada jednej odpowiedzialności)
Każdy moduł lub klasa powinna mieć odpowiedzialność za pojedynczą część funkcjonalności zapewnianej przez oprogramowanie, a odpowiedzialność ta powinna być w całości zawarta w klasie, module lub funkcji. Klasa powinna mieć jeden i tylko jeden powód do zmiany.
– Robert C.Martin (Uncle Bob)
Single Responsibility Principle Czytaj więcej »
W tym artykule oraz kolejnych pięciu postaram się przybliżyć zasady programowania obiektowego SOLID.
Dzięki nim możemy tworzyć uporządkowany, zrozumiały i łatwy w utrzymaniu, ale przede wszystkim cechujący się wysoką elastycznością przy rozbudowywaniu aplikacji i wprowadzaniu zmian kod.
Przykłady zastosowania reguł SOLID przedstawię w języku Java ☕︎.