SOLID Flashcards
SOLID ogolnie
Zasady projektowania, których celem jest zrozumienie projektu oprogramowania, uczycnienie projektu elastycznym i łatwiejszym do utrzymania.
S Single Responsibility Principle
Zasada pojedynczej odpowiedzialności
klasa powinna podlegać zmianie tylko z jednego powodu, powinna być odpowiedzialna tylko za jedną część funkcjonalności. Ta częśc nie powinna być widoczna dla innych klas (hermetyzacja)
Cel redukcja złożoności.
zmniejszenie ryzyka zepsucia całości przy zmianie określonej funkcjonalności
Utrudnienie dokonywania zmian
Przyklad -Employee drukowanie raportów z Employee
Single Responsibility Principle (SRP) to jedna z pięciu zasad SOLID w programowaniu obiektowym. SRP mówi, że klasa lub moduł powinien mieć tylko jedną odpowiedzialność. Innymi słowy, klasa powinna mieć tylko jeden powód do zmiany. Zasada ta zachęca do tworzenia bardziej małych, zrozumiałych i elastycznych klas oraz modułów, co ułatwia utrzymanie i rozwijanie kodu.
Główne punkty Single Responsibility Principle to:
Jedna odpowiedzialność: Klasa lub moduł powinny zajmować się tylko jednym aspektem lub zadaniem w systemie. Jeśli klasa ma wiele różnych odpowiedzialności, może to prowadzić do trudności w zrozumieniu kodu i wprowadzania zmian.
Unikanie nadmiernego skomplikowania: Klasa lub moduł powinny być jak najprostsze i skoncentrowane na jednym celu. Unikanie nadmiernego skomplikowania pozwala na łatwiejsze testowanie i utrzymanie kodu.
Unikanie nadmiernego związku: Klasa nie powinna być nadmiernie związana z innymi klasami. Jeśli klasa ma wiele odpowiedzialności, to jest bardziej zależna od innych klas, co utrudnia zmiany i rozszerzenia.
SRP ma na celu tworzenie bardziej modularnych i zrozumiałych struktur kodu. W praktyce oznacza to, że powinniśmy projektować klasy i moduły w taki sposób, aby były odpowiedzialne za jedno konkretne zadanie lub funkcję. Jeśli klasa lub moduł ma więcej niż jedną odpowiedzialność, warto zastanowić się nad podziałem na mniejsze klasy lub moduły, każdy z jedną odpowiedzialnością.
Dzięki SRP kod staje się bardziej czytelny, elastyczny i łatwiejszy do utrzymania, a zmiany w jednym miejscu nie wpływają na inne części systemu.
O Open/closed principle
Klasy powinny być otwarte na rozszerzenie ale zamknięte na modyfikacje.
Cel uniknięcie popsucia kodu przy implementacji nowej funkcjonalności.
Klasa jest otwarta jeżeli możemy stworzyć jej podklasę. dodawać pola, napisywać zachowanie klasy bazowej.
Po wprowadzeniu FINAL klasa przestaje być otwarta.
W praktyce opracowuje się klasy zamknięte i na ich podstawie tworzy podklasy i nadpisuje elementy, które się zmnieniają
Przykład - klasa zamówienie dodanie nowego sposobu wysyłki to ryzyko popsucia klasy, rozwiązanie zastosowanie wzorca strategia (wydzielenie metod wysyłki do osobnej klasy Wysyłka
Open/Closed Principle (OCP) to jedna z pięciu zasad SOLID w programowaniu obiektowym, zaproponowana przez Bertranda Meyera. Zasada ta głosi, że oprogramowanie powinno być otwarte na rozszerzenia (Open) i zamknięte na modyfikacje (Closed). W skrócie, oznacza to, że istniejące moduły lub klasy nie powinny być zmieniane, gdy dodawane są nowe funkcje lub rozszerzenia, a to powinno być osiągnięte poprzez dziedziczenie, interfejsy lub kompozycję.
Główne punkty Open/Closed Principle to:
Zamknięcie na modyfikacje: Istniejący kod, tzn. klasy lub moduły, nie powinien być zmieniany, aby dodawać nową funkcjonalność. Niezależnie od tego, ile nowych funkcji dodajemy, istniejący kod (klasy bazowe, moduły itp.) powinien pozostać nietknięty.
Otwarcie na rozszerzenia: Zamiast zmieniać istniejący kod, nowe funkcje lub rozszerzenia powinny być dodawane poprzez dziedziczenie, implementację nowych interfejsów lub kompozycję. To oznacza, że nowe klasy powinny być w stanie rozszerzać lub modyfikować zachowanie istniejących klas bez modyfikowania tych klas.
Zachowanie spójności: Istniejące kontrakty, interfejsy i abstrakcje powinny pozostać spójne i niezmienne. Nowe klasy lub moduły powinny dostosowywać się do tych kontraktów.
OCP zachęca do tworzenia elastycznych i łatwych do rozbudowy systemów, w których istniejący kod jest stabilny i nie narażony na niepotrzebne zmiany. Dzięki temu zmiany i rozszerzenia można wprowadzać bez ryzyka wprowadzania błędów i bez konieczności testowania całego systemu od nowa.
W praktyce OCP oznacza stosowanie takich technik jak dziedziczenie, interfejsy, polimorfizm i kompozycja, aby uniknąć modyfikacji istniejącego kodu i umożliwić jego rozszerzalność.
L Liskov Substitution Principle
Zasada podstawienia
Przekazywanie obiektów podklasy w iejsce klasy bazowej.
Zachowanie klasy bazowej i podklasy powinno być kompatybilne.
Określa wymagania wobec podklasy, malo miejsca na własną interpretację.
*zgodne typy parametrów klasy bazowej i podklasy,
*metody powinny zawsze dotyczyć klasy bazowej
*typy obiektow zwracanych też powinny być zgodne w klasie bazowej i podklasie
* poprawne uszczegółowianie
*metoda w podklasie nie powinna rzucać innych wyjątków niż w klasie bazowej
*podklasa nie powinna wzmacniać warunków wstępnych
*podklasa nie powinna osłabiać warunków końcowych
*niezmienniki klasy bazowej muszą zostać zachowane (warunki w jakich obiekt ma sens)
*poklasa nie powinna zmieniać wartości prywatnych pól klasy
Liskov Substitution Principle (LSP) to jedna z pięciu zasad SOLID w programowaniu obiektowym, które zostały sformułowane przez Barbarę Liskov. LSP głosi, że obiekty powinny być zastępowalne przez swoje podtypy (dziedziczące z klasy bazowej) bez wprowadzania niepożądanych efektów ubocznych w programie. W skrócie, jeśli dana klasa jest podtypem innej klasy, to obiekty obu klas powinny być zastępowalne w kodzie, a to nie powinno prowadzić do błędów ani naruszenia spójności systemu.
Główne założenia Liskov Substitution Principle to:
Podtypy muszą być zastępowalne za swoje bazowe typy: Jeśli klasa A jest podtypem klasy B, to obiekt klasy A powinien być w stanie zastąpić obiekt klasy B w kodzie, a kod nie powinien zachowywać się inaczej ani nie powinien wymagać modyfikacji.
Kontrakt podtypu: Podtyp powinien zachowywać się zgodnie z kontraktem (interfejsem lub zachowaniem) swojego nadtypu. Oznacza to, że wszystkie metody i właściwości dostępne w nadtypie powinny być dostępne i zachowywać się zgodnie z oczekiwaniami w podtypie.
Brak naruszenia inwariantów: Operacje wykonywane na obiektach podtypu nie powinny prowadzić do naruszenia inwariantów definiowanych przez nadtyp.
LSP jest ważne, ponieważ zapewnia spójność i pewność działania systemu, zwłaszcza w przypadku dziedziczenia i polimorfizmu w językach programowania. Naruszenie Liskov Substitution Principle może prowadzić do błędów, trudności w zrozumieniu kodu i złamania kontraktów interfejsów i klas bazowych.
W praktyce Liskov Substitution Principle zachęca do projektowania hierarchii klas i interfejsów w sposób, który umożliwia bezpieczne dziedziczenie i używanie podtypów. To pomaga w tworzeniu bardziej elastycznych i niezawodnych systemów.
I Interface Segregation Principle
Zasada segregacji interfejsów
Intefejsy powinny być specjalistyczne, implementujące tylko te zachowania, które są potrzebne.
Jedna klasa bazowa może mieć dużo interfejsów, małe pojedyńcze specjalistyczne intefejsy
Interface Segregation Principle (ISP) jest jedną z pięciu zasad SOLID związanych z projektowaniem interfejsów w programowaniu obiektowym. Zasada ta mówi, że “klienci nie powinni być zmuszani do zależności od interfejsów, których nie używają”. W skrócie, ISP zachęca do tworzenia bardziej szczegółowych interfejsów, które zawierają tylko te metody, które są istotne dla konkretnych klientów, zamiast tworzyć jedno ogólne, wielozadaniowe interfejsy, które wymagają implementacji niepotrzebnych funkcji.
Główne punkty ISP to:
Tworzenie cienkich interfejsów: Interfejsy powinny być projektowane tak, aby były cienkie i zawierały tylko te metody, które są istotne dla konkretnego klienta. Unika się tworzenia interfejsów, które narzucają implementacje niepotrzebnych funkcji.
Unikanie “tłustych” interfejsów: “Tłuste” interfejsy to te, które zawierają wiele metod, niektóre z nich mogą być niepotrzebne dla niektórych klientów. To prowadzi do sytuacji, w której implementujący klasy muszą dostarczyć implementacje wszystkich metod, nawet jeśli nie są używane.
ISP ma na celu poprawienie elastyczności i zrozumiałości kodu. Ułatwia to klientom korzystanie tylko z tych funkcji, które są dla nich istotne, zamiast być zmuszonymi do implementacji zbędnych metod. Dzięki temu kod staje się bardziej zrozumiały, elastyczny i łatwiejszy do utrzymania.
ISP jest szczególnie ważne w kontekście interfejsów w językach programowania, ponieważ pozwala na tworzenie bardziej dopasowanych do potrzeb klientów interfejsów i unika narzucania zbędnych obowiązków implementującym klasom.
D Dependency Inversion Principle
Zasada odwróconej zależności
Klasy wysokopoziomowe(logika biznesowa) nie powinny być zależne od niskopoziomowych(podstawowe operacje).
Powszechne podejście implementacja najpierw niskopoziomowych a potem wysokopoziomowych, ta zasada zaleca zmianę takiego sposobu myślenia.
Zasada odwrócenia zależności (Dependency Inversion Principle, DIP) jest jednym z pięciu zasad związanych z zasadami SOLID w programowaniu obiektowym. DIP skupia się na rozdzieleniu modułów i ich zależności oraz promuje luźne powiązania między nimi. Zasada ta skupia się na następujących głównych koncepcjach:
Wysoki poziom modułu nie powinien zależeć od niskiego poziomu. Oba powinny zależeć od abstrakcji.
Oznacza to, że moduły na różnych poziomach abstrakcji powinny korzystać z ogólnych interfejsów lub klas bazowych, a nie odwrotnie. Dzięki temu unikamy bezpośrednich zależności między modułami o różnych poziomach, co sprawia, że zmiany w jednym module nie wpływają bezpośrednio na inny.
Abstrakcje nie powinny zależeć od szczegółów. Szczegóły powinny zależeć od abstrakcji.
Oznacza to, że ogólne abstrakcje (interfejsy lub klasy bazowe) nie powinny zależeć od konkretnych implementacji. To implementacje powinny dostosowywać się do ogólnych abstrakcji. Dzięki temu unikamy, aby zmiany w szczegółach miały wpływ na wyższy poziom kodu.
W praktyce DIP jest często realizowane za pomocą mechanizmów wstrzykiwania zależności (Dependency Injection) oraz stosowania interfejsów i abstrakcji w projektach. Dzięki temu kod staje się bardziej elastyczny, łatwiejszy do testowania i mniej narażony na zmiany w implementacjach.
DIP pomaga w tworzeniu bardziej rozszerzalnych i elastycznych systemów, gdzie zmiany w jednym module nie wymagają dużych zmian w innych. To jedna z zasad, które przyczyniają się do tworzenia trwałych i łatwych w utrzymaniu systemów.
