Zasady SOLID stanowią kluczowy zestaw wytycznych w programowaniu obiektowym, skupiających się na promowaniu czystego, modularnego i łatwego w utrzymaniu kodu. Przyjęcie tych pięciu zasad — Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation oraz Dependency Inversion — znacząco przyczynia się do poprawy jakości oprogramowania. Ich stosowanie umożliwia deweloperom tworzenie skalowalnych i elastycznych systemów, które są odporne na zmiany i ułatwiają współpracę w zespołach. Poznaj bliżej zasady SOLID — programowanie może stać się łatwiejsze!
DIP mówi o tym, że moduły wysokopoziomowe nie powinny być zależne od modułów niskopoziomowych, ich zależności powinny wynikać z abstrakcji (stosowanie interfejsów i klas abstrakcyjnych). Ponadto abstrakcje nie powinny zależeć od szczegółów tylko odwrotnie, szczegóły powinny zależeć od abstrakcji. Mamy klasę Manager, która jest klasą na wysokim poziomie, oraz klasę niskiego poziomu zwaną Sms. I […]
Dependency Inversion Principle Read More »
Teraz omówimy zasadę segregacji interfejsów jest to czwarta zasada SOLID, która opisuje, jak powinniśmy projektować i używać interfejsy w naszych aplikacjach. Zasada ta stanowi, że klienci (klasy) nie powinni być zmuszani do polegania na metodach, których nie używają. Kilka dedykowanych interfejsów jest lepsze niż jeden, który jest zbyt ogólny. Następstwem tego jest to, że powinniśmy
Interface Segregation Principle Read More »
Teraz porozmawiamy o zasadzie podstawiania Liskov. Zasada podstawiania Liskov lub LSP, to trzecia z zasad SOLID która mówi, że: Funkcje, które używają wskaźników lub referencji do klas bazowych,muszą być w stanie używać również obiektów klas dziedziczącychpo klasach bazowych, bez dokładnej znajomości tych obiektów. W miejsce typu bazowego możesz podstawić dowolny typ klasy pochodnej i nie powinieneś
Liskov Substitution Principle Read More »
OCP mówi o tym, że klasy, moduły bądź funkcje powinny być otwarte na rozbudowę, rozszerzanie, a zamknięte na modyfikacje. Zasada ta wymusza stosowanie abstrakcji, ponieważ w programie powinna być wydzielona część wspólna i specyficzna. Część wspólna powinna być zamknięta w interfejsie lub klasie abstrakcyjnej, zaś część specyficzna powinna znajdować się w konkretnej klasie, która implementuje
Open/Closed Principle Read More »
SRP mówi o tym, że dana klasa powinna zajmować się jedną funkcjonalnością. Nie oznacza to, że może posiadać tylko jedną metodę, może mieć więcej metod, ale takich które są związane z daną funkcjonalnością. Za przykład posłuży program do przeliczania stopni Celsjusza na Fahrenheita i odwrotnie. Zły kod przedstawia klasę Assistant, która posiada jedną metodę, która
Single Responsibility Principle Read More »
