Czym jest SOLID?
SOLID to zbiór dobrych praktyk w programowaniu obiektowym. Przestrzeganie tych zasad pomaga sprawić, że nasz kod jest bardziej zrozumiały, łatwiejszy w zarządzaniu, elastyczny na zmiany. SOLID to akronim wymyślony przez Michaela Feathersa. Ta metodologia została poparta przez Twórców czystego kodu m.in.: przez Roberta C. Martina.
5 podstawowych zasad
Często programiści mają problem ze zrozumieniem sensu i potrzeby stosowania zasad SOLID. Większość z programistów potrafi podać 5 zasad SOLID, jednak mniejszość potrafi dobrze zastosować je w swoim kodzie.
Pamiętajmy, że zasady SOLID są wskazówką, pomocą dla programistów. Czasami nie wszystkie zasady mogą być spełnione na 100%, czasami trzeba wybrać „mniejsze zło”.
S – SRP – Single Responsibility Principle
Jest to zasada pojedynczej odpowiedzialności. Oznacza to, że klasa lub metoda powinna posiadać tylko jedną odpowiedzialność. Nie powinien istnieć więcej niż jeden powód, aby zmodyfikować naszą klasę.
Jest to najprostsza, najczęściej używana i najbardziej przydatna zasada.
O – OCP – Open Close Principle
Zasada otwarte-zamknięte. Klasy powinny być zamknięte na modyfikacje i otwarte na rozszerzenia. Nie powinniśmy zmieniać istniejącego kodu, powinniśmy dokonać zmian w kodzie poprzez rozszerzenie kodu.
L – LSP – Liskov Substitution Principle
Zasada podstawienia Liskov. Klasa dziedzicząca powinna rozszerzać klasę bazową bez wpływu na jej aktualne działanie. Oznacza to, że w miejscu klasy bazowej możemy użyć klasy dziedziczącej. Wszystkie metody w klasie dziedziczącej muszą przyjmować te same argumenty i zwracać te same typy co w klasie bazowej (Klasa pochodna zachowuje 100% interfejsu klasy bazowej).
I – ISP – Interface Segregation Principle
Zasada segregacji interfejsów. Nie powinniśmy używać interfejsów, które deklarują wiele metod, jeżeli którakolwiek z nich może być niewykorzystana. Lepiej mieć wiele dedykowanych interfejsów niż jeden ogólny. Każdy interfejs powinniśmy tworzyć w taki sposób, aby zawierał tylko niezbędne metody. Wszystkie inne metody, które nie są używane powinny znaleźć się w innych interfejsach.
D – DIP – Dependency Inversion Principle
Zasada odwracania zależności. Według tej zasady moduły wysokopoziomowe nie powinny zależeć od modułów niskopoziomowych. Zależność pomiędzy modułami powinna wynikać z abstrakcji. Dokładnie chodzi o to, że nie powinniśmy operować bezpośrednio na instancjach naszych zmiennych, klas, obiektów, metod. Powinniśmy operować bezpośrednio na ich interfejsach, które są ich warstwami abstrakcyjnymi. Pozwalają one na rozbudowę i dokonywanie zmian
0 komentarzy