W swojej pracy programistycznej postępuję zgodnie z zasadami S.O.L.I.D

"S" (Single Responsibility) - Zasada jednej odpowiedzialności.
„Klasa powinna wykonywać tylko jedno zadanie oraz powinien występować tylko jeden powód aby ją zmienić (modyfikować)” Prawdopodobnie najważniejsza zasada, aby napisać „czysty kod”, aby klasa była czytelna, łatwa w utrzymaniu i rozbudowywaniu. Pozstępowanie zgodnie z tą zasadą gwarantuje pisanie funkcji / metod które wykonują tylko jedno zadanie.

Główne zalety:

• czytelność kodu,
• łatwość w testowaniu,
• możliwość ponownego użycia kodu,
• łatwość w utrzymaniu.

"O" (Open-Close) - Zasada otwarte / zamknięte.
„Klasy, metody czy funkcje powinny być otwarte na rozbudowywanie ale zamknięte na modyfikowanie” Idea tej zasady polega na zapewnieniu klasom, metodom czy funkcjom możliwości rozbudowywania w przyszłości w razie potrzeby. Nowe funkcjonalności mogą być dodawane, bez wprowadzania błędów w kompilacji programu. Można dodawać nowe cechy pisząc nowe linie kodu bez modyfikowania już napisanego „starego” kodu.

Główne zalety:

• łatwość w utrzymaniu,,
• niezawodność.

"L" (Liskov Substitution) - Zasada podstawienia Liskov.
„Funkcje które używają referencji do klas bazowych, muszą być w stanie używać również obiektów klas dziedziczących po klasach bazowych, bez dokładnej znajomości tych obiektów”

"I" (Interface Segregation) - Zasada segregacji interfejsów.
„Klasa dziedzicząca (klient) nigdy nie powinien być zmuszany do implementacji interfejsu którego nie używa, oraz klasa dziedzicząca nie powinna być uzależniona od metody której nie używa.”
Zasada ta pomaga w rozwiązywaniu problemów z dużymi, rozbudowanymi interfejsami które są ciężkie w implementacji przez klasy dziedziczące (klienta).

"D" (Dependency Inversion) - Zasada odwrócenia zależności.
„Klasy muszą polegać na abstrakcji a nie na zależności. To znaczy, że klasa wysokiego poziomu nie może być uzależniona od klasy niskiego poziomu, ale obie klasy powinny zależeć od abstrakcji.”