SOLID’ny kod według wujka Boba

Posted on by 0 comment

Spoglądając na statystyki odwiedzin bloga, stwierdzam, że ktoś tu wchodzi. Jestem miło zaskoczony, że grono to systematycznie się powiększa, co mnie niezmiernie cieszy. Ostatnim czasy próbując przypomnieć sobie schemat implementacji wzorca kompozyt, po wpisaniu w wyszukiwarce słów „c# kompozyt”, moim oczom ukazał się jako pierwszy, odnośnik do mojego bloga, bardzo pozytywne uczucie, które przekonuje mnie do częstszego wypełniania tej strony treścią.

Przez ostatnie chwile szukałem pomysłu na artykuł. Pomyślałem, że najłatwiej będzie zacząć od wyjaśnienia zasad jakiegoś wzorca projektowego, ale jakiego? Próbując złapać myśl, przypomniałem sobie opinię, którą zresztą podzielam, że podstawą czystego i czytelnego kodu, jest zachowanie 5 zasad dobrego programowania (tak zwane SOLID), zaproponowanych przez Robert C. Martin‚a. O tym podejściu napiszę w tym artykule oraz w kilku następnych.

SOLID - 5 zasad dobrego oprogramowania

SOLID – 5 zasad dobrego oprogramowania

„Czysty kod” Robert C. Martin – recenzja

Pierwszy raz zetknąłem się z książką „Czysty kod”, po tym, jak pozwoliłem sobie poprosić o wskazówki na przyszłość, po nieudanej rekrutacji na stanowisko deweloperskie. Po kilku rozdziałach jedną z myśli, która nasunęła mi się do głowy, było stwierdzenie „ja nie umiem programować” 🙂 Polecam każdemu juniorowi, seniorowi i lekarzowi. Kilkadziesiąt pierwszych stron zawiera naprawdę garść cennych informacji, jak ułatwić sobie i spadkobiercom kodu, pracę w przyszłości. Wujek Bob interesująco wprowadza w banalne mogłoby się wydawać tematy nazw zmiennych, metod, klas, ale równocześnie nie pozostawia bez pomocy, gdy chcemy tworzyć przystępny i poprawny kod w aplikacjach pracujących na wielu wątkach. Pozycja nakreśla sens tworzenia czystego kodu oraz korzyści z tego płynące.

Osobiście uważam, że czysty kod to satysfakcja, programiści zwykle lubią, to co robią, bo jak inaczej można zostać programistą, więc dlaczego nie robić by tego dobrze, profesjonalnie. Wracając do „Czystego kod”, przeczytałem niejednokrotnie i jestem pewien, że jeszcze nie raz wrócę.

SOLID ~> wzorce projektowe

Wracając do tematu jakości kodu. Każdy doświadczony developer, zgodzi się ze stwierdzeniem, że nie sztuką jest napisać kod, ale sztuką jest go później na przestrzeni lat sukcesywnie rozwijać i utrzymywać. Niedbałość, brak testów, postawa „żeby tylko działało” doprowadziła już w historii nie jeden projekt do upadku. Reakcją na tego typu sytuację, zapewnienie sobie intuicyjności kodu w przyszłości było/jest implementowanie wzorców projektowych. Deterministyczne podejście, w niektórych kręgach doprowadziło, że jakość projektu definiowano przez ilość zdefiniowanych wzorców. Trochę niezrozumiałe, prawda? To tak jakby o prędkości auta, decydowała liczba kierowców w nim podróżujących.

Ostatnim czasy, między innymi dzięki takim ludziom jak wspomniany już wcześniej wujek Bob, propagowane i popularne jest tworzenie kodu zgodnego z regułami SOLID. SOLID to 5 reguł, które w logiczny sposób ułatwiają późniejsze rozwijanie i czytanie obcego oprogramowania. Jest to swego rodzaju trend w programowaniu, który jest tak samo popularny, jak ostatnim czasy podejście Agile. O każdej z reguł wspominam poniżej, a ze szczegółami możesz zapoznać się w osobnym artykule. Reguła SOLID nie jest jakąś skomplikowaną techniką, jej implementacja polega na trzymaniu się 5 zasad. Jeśli w trakcie programowania lub w czasie refactoringu, uznasz, że coś powinno być zrobione inaczej to po prostu to przeprojektowujemy, zmieniamy. Sam Robert C. Martin w podręczniku „Czysty kod” wielokrotnie przedstawia wieloetapowy proces doskonalenia swojego kodu, zmieniania struktury, nazw itp., a więc nie bójmy się zmian 🙂

Czy to oznacza, że mamy zaprzestać stosować wzorce projektowe? Nie. Nie implementujmy ich tylko za wszelką cenę, ani, co gorsza na ilość. Średnio doświadczony, myślący programista, tworzący oprogramowanie rozpozna sytuację, w których implementacja odpowiedniego wzorca projektowego ułatwi tworzenie dobrej jakości oprogramowania. Powiedzmy, że sytuacja sama rozwinie się w czasie projektowania, pisania systemu.

SOLID

S – Single responsibility principle, czyli Zasada jednej odpowiedzialności. Klasa powinna mieć tylko jedną odpowiedzialność.

O – Open/closed principle, czyli  Zasada otwarte-zamknięte. Oprogramowanie powinno być otwarte na rozszerzanie, ale zamknięte na modyfikacje.

L – Liskov substitution principle, czyli Zasada podstawienia Liskov. Powinno być możliwe podstawienie instancji klasy pochodnej za klasę bazową.

I – Interface segregation principle, czyli Zasada segregacji interfejsów. Kod powinien składać się z wielu małych interfejsów, a nie jednego dużego.

D – Dependency inversion principle, czyli Zasada odwrócenia zależności. Wysokopoziomowe moduły, nie powinny zależeć od modułów niskopoziomowych.

Podsumowanie

SOLID to nieodłączny element dobrego programisty, dlatego zachęcam do lektury następnych 5 wpisów, w których szerzej przedstawię każdą z zasad. Starając się tworzyć przystępne oprogramowanie, warto zapoznać się z chociaż kilkoma wzorcami projektowymi, do lektory o wzorcach projektowych zapraszam do specjalnej serii artykułów.

Category: Programowanie, Solid | Tags: ,

Dodaj komentarz