Dość często spotykam programistów, którzy nie słyszeli o zasadach SOLID (my . — Tłum.) lub programowanie obiektowe (OOP) lub słyszałeś o nich, ale nie stosujesz ich w praktyce. W tym artykule opisano zalety zasad OOP, które pomagają programiście w jego codziennej pracy. Niektóre z nich są dobrze znane, inne mniej, dlatego artykuł będzie przydatny zarówno dla początkujących, jak i doświadczonych programistów.
Przypomnienie: dla wszystkich czytelników Habr - rabat 10 000 rubli przy zapisie na dowolny kurs Skillbox przy użyciu kodu promocyjnego Habr.
Skillbox poleca: Kurs edukacyjny on-line .
SUCHY (nie powtarzaj się)
Dość prosta zasada, której istota jest jasna od nazwy: „Nie powtarzaj się”. Dla programisty oznacza to konieczność unikania powielania kodu, a także możliwość wykorzystania abstrakcji w swojej pracy.
Jeśli w kodzie występują dwie powtarzające się sekcje, należy je połączyć w jedną metodę. Jeśli wartość zakodowana na stałe zostanie użyta więcej niż raz, warto ją przekonwertować na stałą publiczną.
Jest to konieczne, aby uprościć kod i ułatwić jego utrzymanie, co jest głównym celem OOP. Nie powinieneś też nadużywać unii, ponieważ ten sam kod nie przejdzie weryfikacji zarówno z OrderId, jak i numerem SSN.
Hermetyzacja zmian
Oprogramowanie większości firm stale się rozwija. Oznacza to, że trzeba wprowadzić zmiany w kodzie, trzeba go wesprzeć. Możesz ułatwić sobie życie, stosując enkapsulację. Umożliwi to efektywniejsze testowanie i utrzymywanie istniejącej bazy kodu. .
Jeśli piszesz w Javie, to .
Zasada otwarty/zamknięty
Zasadę tę łatwo zapamiętać czytając następujące stwierdzenie: „Jednostki oprogramowania (klasy, moduły, funkcje itp.) powinny być otwarte na rozbudowę, ale zamknięte na modyfikację”. W praktyce oznacza to, że mogą pozwolić na zmianę swojego zachowania bez zmiany kodu źródłowego.
Zasada jest ważna, gdy zmiany w kodzie źródłowym wymagają rewizji kodu, testów jednostkowych i innych procedur. Kod zgodny z zasadą otwarty/zamknięty nie zmienia się po rozszerzeniu, więc jest z nim znacznie mniej problemów.
Oto przykład kodu naruszającego tę zasadę.
Jeśli chcesz coś w nim zmienić, zajmie to dużo czasu, ponieważ wszystkie sekcje kodu powiązane z żądanym fragmentem będą musiały zostać zmienione.
Swoją drogą otwartość-zamkniętość to jedna z zasad SOLID-u.
Zasada pojedynczej odpowiedzialności (SRP)
Kolejna zasada z zestawu SOLID. Stwierdza, że „jest tylko jedna przyczyna powodująca zmianę klasy”. Klasa rozwiązuje tylko jeden problem. Może mieć kilka metod, ale każda z nich służy tylko do rozwiązania wspólnego problemu. Wszystkie metody i właściwości powinny służyć tylko temu.
Wartość tej zasady polega na tym, że rozluźnia ona powiązanie pomiędzy indywidualnym komponentem oprogramowania a kodem. Jeśli dodasz więcej niż jedną funkcjonalność do klasy, wprowadza to relację między dwiema funkcjami. Zatem jeśli zmienisz jeden z nich, istnieje duża szansa na zniszczenie drugiego, który jest połączony z pierwszym. A to oznacza zwiększenie liczby cykli testowych, aby z wyprzedzeniem zidentyfikować wszystkie problemy.
Zasada odwrócenia zależności (DIP)
Powyżej znajduje się przykład kodu, w którym AppManager zależy od EventLogWriter, który z kolei jest ściśle powiązany z AppManager. Jeśli potrzebujesz innego sposobu wyświetlania powiadomienia, czy to w trybie push, SMS czy e-mail, musisz zmienić klasę AppManager.
Problem można rozwiązać za pomocą DIP. Dlatego zamiast AppManager żądamy EventLogWriter, który zostanie wprowadzony za pomocą frameworka.
DIP umożliwia łatwą wymianę poszczególnych modułów na inne poprzez zmianę modułu zależności. Dzięki temu możliwa jest zmiana jednego modułu bez wpływu na pozostałe.
Skład zamiast dziedziczenia
Istnieją dwa główne sposoby ponownego użycia kodu: dziedziczenie i kompozycja, oba mają swoje zalety i wady. Zwykle preferowany jest drugi sposób, ponieważ jest bardziej elastyczny.
Kompozycja umożliwia zmianę zachowania klasy w czasie wykonywania poprzez ustawienie jej właściwości. Przy implementacji interfejsów stosuje się polimorfizm, co daje bardziej elastyczną implementację.
Nawet Efektywna Java autorstwa Joshuy Blocha radzi wybierać kompozycję zamiast dziedziczenia.
Barbara Liskov Zasada substytucji (LSP)
Kolejna zasada z zestawu narzędzi SOLID. Stwierdza, że podtypy muszą być substytucyjne dla nadtypu. Oznacza to, że metody i funkcje działające z nadklasą powinny móc bez problemów współpracować z jej podklasami.
LSP jest kojarzony zarówno z zasadą pojedynczej odpowiedzialności, jak i zasadą wspólnej odpowiedzialności. Jeśli klasa zapewnia więcej funkcjonalności niż podklasa, to ta ostatnia nie będzie obsługiwać niektórych funkcjonalności, naruszając tę zasadę.
Oto fragment kodu, który jest sprzeczny z LSP.
Metoda area(Rectangle r) oblicza pole prostokąta. Program ulegnie awarii po wykonaniu polecenia Kwadrat, ponieważ Kwadrat nie jest tutaj prostokątem. Zgodnie z zasadą LSP funkcje korzystające z referencji do klas bazowych powinny mieć możliwość korzystania z obiektów klas pochodnych bez dodatkowych instrukcji.
Zasada ta, będąca specyficzną definicją podtypu, została zaproponowana przez Barbarę Liskov w przemówieniu konferencyjnym z 1987 roku zatytułowanym „Data Abstrakcja i hierarchia”, stąd jej nazwa.
Zasada separacji interfejsów (ISP)
Kolejna SOLIDNA zasada. Zgodnie z nią nie należy wdrażać interfejsu, który nie jest używany. Przestrzeganie tej zasady pomaga systemowi zachować elastyczność i nadawać się do refaktoryzacji po wprowadzeniu zmian w logice działania.
Najczęściej taka sytuacja ma miejsce, gdy interfejs zawiera kilka funkcji jednocześnie, a klient potrzebuje tylko jednej z nich.
Ponieważ napisanie interfejsu jest trudnym zadaniem, jego zmiana po zakończeniu pracy bez psucia czegokolwiek będzie wyzwaniem.
Zaletą zasady ISP w Javie jest to, że wszystkie metody muszą być najpierw zaimplementowane, a dopiero potem mogą być wykorzystywane przez klasy. Zasada ta umożliwia zatem redukcję liczby metod.
Programowanie pod interfejs, a nie implementacja
Wszystko tutaj jest jasne od nazwy. Zastosowanie tej zasady prowadzi do stworzenia elastycznego kodu, który może współpracować z każdą nową implementacją interfejsu.
Powinieneś używać typu interfejsu dla zmiennych, typów zwracanych lub typu argumentu metody. Przykładem jest użycie SuperClass zamiast SubClass.
To jest:
Lista numerów= getNumbers();
Ale nie:
Numery ArrayList = getNumbers();
Oto praktyczna implementacja tego, co omówiono powyżej.
Zasada delegacji
Typowym przykładem są metody równości() i hashCode() w Javie. Gdy konieczne jest porównanie dwóch obiektów, akcja ta jest delegowana do odpowiedniej klasy, a nie do klasy klienckiej.
Zaletą tej zasady jest to, że nie ma powielania kodu i stosunkowo łatwo jest zmienić zachowanie. Dotyczy to również delegowania wydarzeń.
Wszystkie te zasady pozwalają pisać bardziej elastyczny, piękny i niezawodny kod o wysokiej spójności i niskim sprzężeniu. Oczywiście teoria jest dobra, ale aby programista mógł faktycznie wykorzystać zdobytą wiedzę, potrzebna jest praktyka. Po opanowaniu zasad OOP następnym krokiem może być poznanie wzorców projektowych w celu rozwiązywania typowych problemów związanych z tworzeniem oprogramowania.
Skillbox poleca:
- Kurs praktyczny .
- Stosowany kurs online .
- Dwuletni kurs praktyczny .
Źródło: www.habr.com