Single Responsibility Principle (SRP)
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 wykonuje aż 4 czynności: konwertuje stopnie Celsjusza na Fahrenheita i odwrotnie oraz wyświetla wyniki. Prawidłowy kod jest rozbity na klasy, gdzie jedna zajmuje się konwertowaniem temperatur, zaś druga ich wyświetlaniem.
ZŁY KOD
DOBRY KOD
Open/Closed Principle (OCP)
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 dany interfejs lub dziedziczy daną klasę abstrakcyjną. Zły kod przedstawia jedną klasę Figure, gdzie znajduje się jedna metoda liczącą obwód kwadratu i prostokąta. Jeżeli chcielibyśmy rozszerzyć implementację o następną figurę to potrzebna jest modyfikacja całej metody. W dobrym kodzie został wydzielony interfejs Figure, który implementują poszczególne figury. Dzięki takiemu rozwiązaniu łatwo jest dodać kolejne klasy figur z zachowaniem niezmienionego interfejsu.
ZŁY KOD
DOBRY KOD
Liskov Substitution Principle (LSP)
LSP mówi o tym, że, jeżeli w kodzie występuje dziedziczenie to w miejsce klasy nadrzędnej powinna byc możliwość podstawienia dowolnej klasy podrzędnej. Musi być więc zachowana zgodność interfejsów jak i wszystkich metod. Zły kod pokazuje klasę nadrzedną Bird oraz dwie klasy, które są o nią rozszerzane: Crow i Ostrich. Klasa Ostrich nie mogłaby zastąpić klasy nadrzędnej, ponieważ klasa Bird wymusza implemetnację metody fly(). W przypadku strusia ta metoda nie jest odpowiednia, ponieważ ptaki te nie latają. Poprawny kod składa się również z klasy nadrzędnej Bird ale usunięto z niej metodę fly(). Teraz klasa Ostrich może być rozszerzona o tę klasę. W przypadku klasy Crow zastosowano dziedziczenie po klasie FlyingBirds, która jest rozszerzeniem klasy Bird.
ZŁY KOD
DOBRY KOD
Interface Segregation Principle (ISP)
ISP jest to zasada, która mówi, że lepiej jest utworzyć kilka mniejszych interfejsów niż jeden duży. Pozbywamy się tym samym problemu implementacji metod, których klasy nie potrzebują. Zasadę tę przedstawię na przykładzie pizzy. W złym kodzie jest jeden interfejs Pizza, który jest implementowany przez wszystkie rodzaje pizzy. Tym sposobem klasy MargheritaPizza, SalamiPizza i FruttiDiMarePizza posiadają metody, których nie wykorzystują, np. FruttidiMarePizza nie powinna posiadać metody dodającej salami, a SalamiPizza metod dodających owoce morza. W dobrym kodzie duży interfejs Pizza został podzielony na mniejsze interfejsy: Pizza, Meat i Seafood. Teraz każdy rodzaj pizzy implementuje podstawowy interfejs Pizza i dodatkowo interfejs Meat lub Seafood w zależności od typu.
ZŁY KOD
DOBRY KOD
Dependency Inversion Principle (DIP)
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. W złym kodzie klasa Library jest modułem wysokopoziomowym i zależy od klasy BookRepository czyli modułu niskopoziomowego. W dobrym kodzie klasa BookRepository implementuje interfejs Repository, dzięki temu w klasie Library nie polegamy już na klasie BookRepository tylko na interfejsie Repository. Teraz biblioteka nie zależy od konkretnej implementacji BookRepository, a zależy od abstrakcji, tutaj interfejsu, przez co zmiany w module niskopoziomowym nie mają wpływu na moduł wysokopoziomowy.
ZŁY KOD
DOBRY KOD
