Jak Zastosować 5 Zasad SOLID W Swoich Aplikacjach?

SOLID – Podstawowe założenia programowania obiektowego.
Zastosowanie dobrych praktyk podczas tworzenia aplikacji.

Postaram się wam teraz przedstawić ogólne zasady, jakie powinny być stosowane aby pisać dobry kod. Zapewne wszyscy chcielibyśmy aby nasze aplikacje jak i ich architektura była jak najwyższej jakości. Dlatego wszyscy powinniśmy się starać aby tworzony przez nas kod nie zamienił się w kod ala spagetti kod, czyli kod który jest bardzo kruchy, kod który będzie sprawiał nam problemy kiedy będziemy chcieli go zmodyfikować.

Każdy z nas, każdy programista w swojej karierze ma różne etapy i każdy programista w pewnym momencie swojej kariery zawodowej dojdzie do takiego momentu, w którym zechce poprawić jakość tworzonego przez siebie kodu. Widzimy, że nasz kod, który został wcześniej napisany, nie jest najlepszy jest ciężki do utrzymywania. Każde kolejne w nim zmiany są coraz trudniejsze do wprowadzenia. Zastanawiamy się jak to zmienić, jak pisać lepszy, czystszy kod. 🙂

Zasady projektowe SOLID są kolekcją najlepszych praktyk, jakie możemy zastosować w programowaniu. SOLID obejmują pięć indywidualnych zasad, reguł dotyczących programowania obiektowego, tworzenia lepszego oprogramowania. Zasady te stanowią doskonałe wskazówki dla programistów, którzy chcą tworzyć oprogramowanie łatwe do testowania i do utrzymania.

Zasady te zaproponował amerykański programista Robert C. Martin znany jako wujek Bob uważany przez wielu jako autorytet w świecie programowania. Wujek Bob słynie przede wszystkim ze swojego podejścia do czystego kodu. (Czysty Kod Podręcznik Dobrego Programisty).

Czym jest SOLID?

SOLID jest zbiorem dobrych praktyk architektonicznych w programowaniu obiektowym, pomagającym sprawić aby nasz kod był bardziej zrozumiały, czytelny, testowalny, elastyczny na zmiany i łatwiejszy w zarządzaniu.

SOLID – to przydatny skrót akronim, który możemy używać do zapamiętania pięciu ważnych zasad dotyczących tworzenia oprogramowania. Jest to skrót od pierwszych liter tych zasad.

Te zasady to :

• Zasada pojedynczej odpowiedzialności (ang. Single-Responsibility Principle – SRP),
• Zasada otwarte – zamknięte (ang. Open/Closed Principle – OCP),
• Zasada podstawiania Liskov (ang. Liskov Substitution Principle – LSP),
• Zasada segregacji interfejsów (ang. Interface Segregation Principle – ISP),
• Zasada odwracania zależności (ang. Dependency Inversion Principle – DIP).

SOLID jest zatem skrótem opisującym podstawowe założenia programowania obiektowego.

​Dlaczego SOLID?

W miarę rozbudowy naszej aplikacji, która rozrasta się w wielu kierunkach, powstaje również wiele błędów w naszym programie. I każda dodatkowa modyfikacja czy próba naprawy naszego kodu staje się coraz bardziej trudna, skomplikowana i wolna, zajmuje coraz więcej czasu. A SOLID jest zbiorem dobrych praktyk, które pomogą nam budować naszą aplikacje tak aby tych problemów uniknąć. I programiści gdy poznają już zasady SOLID, często zadają sobie pytanie.

Kiedy powinniśmy je zastosować?

No oczywiście kiedy już nauczymy się tych zasad, przekonamy się, że ich zastosowanie może być kuszące zawsze, wszędzie, w każdej sytuacji przez cały czas. 🙂

No dobrze OK, te zasady są świetne, super, ale powinniśmy ćwiczyć coś takiego, co nazywamy w programowaniu PDD, kiedy tylko rozważamy czy mamy zastosować SOLID w naszej aplikacji.

Prawdopodobnie słyszeliście już o :
TDD czyli programowanie sterowane testami lub
DDD czyli projektowanie oparte na domenie, ale być może nie słyszeliście jeszcze o
PDD to programowanie które wywołuje ból przy rozwój naszej aplikacji.

Czyli co to oznacza?

Oznacza to, że najpierw powinniśmy napisać nasz kod przy użyciu najprostszej techniki jaką znamy, aby rozwiązać problem który mamy do rozwiązania aby nasz kod po prostu działał wykonywał swoje zadanie zgodnie z założeniami. Nie martwiąc się w ogóle o zasady, reguły SOLID.

Próba zastosowania wszystkich zasad SOLID od razu na początku jest przedwczesna to jest przedwczesna optymalizacja naszej aplikacji. Zamiast tego, powinniśmy w miarę rozwoju naszej aplikacji i dalszej pracy z nią, spojrzeć w miejsca w których praca z tą aplikacją jest bolesna, trudna i staje się skomplikowana.

I ten ból (PDD) ta trudność może objawiać się jako trudność w testowaniu, nadmiernym powielaniu kodu, zbyt dużym sprzężeniem itp. I Kiedy poczujemy ten ból tą niemoc :), wtedy powinniśmy sprawdzić, czy któraś z zasad SOLID nie może zostać zastosowana i zastosować ją, aby złagodzić ból i poprawić nasz projekt, jakość naszego kodu.