SOLID

(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)

(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)

(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

(Zasada otwarte zamknięte)
Jednostki oprogramowania (klasy, moduły, funkcje itp.) powinny być otwarte na rozszerzanie, ale zamknięte na modyfikacje.
– Meyer Bertrand

(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)

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 ☕︎.