W rozwoju oprogramowania, Projektowanie obiektowe odgrywa kluczową rolę, jeśli chodzi o pisanie elastycznego, skalowalnego, łatwego w utrzymaniu i wielokrotnego użytku kodu. Jest wiele korzyści płynących z używania OOD, ale każdy programista powinien znać także zasadę SOLID, niezbędną do dobrego projektowania obiektowego w programowaniu. Zasada SOLID została wprowadzona przez Roberta C. Martina, znanego również jako Wujek Bob i jest to standard kodowania w programowaniu. Zasada ta jest akronimem pięciu zasad podanych poniżej:

• Zasada pojedynczej odpowiedzialności (SRP)
• Zasada otwarta/zamknięta
• Zasada substytucji Liskova (LSP)
• Zasada segregacji interfejsu (ISP)
• Zasada inwersji zależności (DIP)

Zasada SOLID pomaga w zmniejszeniu ciasnego połączenia. Ścisłe powiązanie oznacza, że ​​grupa klas jest w dużym stopniu od siebie zależna, czego należy unikać w swoim kodzie.

• Przeciwieństwem ścisłego powiązania jest luźne powiązanie i Twój kod jest uważany za dobry, jeśli ma luźno powiązane klasy.
• Luźno powiązane klasy minimalizują zmiany w kodzie, pomagają uczynić kod bardziej użytecznym, łatwiejszym w utrzymaniu, elastycznym i stabilnym. Omówmy teraz po kolei te zasady…

1. Zasada pojedynczej odpowiedzialności

Zasada ta stanowi, że Klasa powinna mieć tylko jeden powód do zmiany co oznacza, że ​​każda klasa powinna mieć jedną odpowiedzialność, jedno zadanie lub jeden cel. Innymi słowy, klasa powinna mieć tylko jedno zadanie lub cel w systemie oprogramowania.

stoi

Przyjrzyjmy się zasadzie pojedynczej odpowiedzialności na przykładzie:

Wyobraź sobie piekarza odpowiedzialnego za pieczenie chleba. Rolą piekarza jest skupienie się na zadaniu wypieku chleba, dbanie o to, aby chleb był wysokiej jakości, odpowiednio wypieczony i spełniał standardy piekarni.

pisanki na Androida

• Jeżeli jednak piekarz jest również odpowiedzialny za zarządzanie zapasami, zamawianie dostaw, obsługę klientów i sprzątanie piekarni, stanowi to naruszenie SRP.
• Każde z tych zadań wiąże się z odrębną odpowiedzialnością, a połączenie ich może obniżyć koncentrację piekarza i jego skuteczność w pieczeniu chleba.
• Aby przestrzegać SRP, piekarnia może przypisać różne role różnym osobom lub zespołom. Na przykład może być osobna osoba lub zespół odpowiedzialny za zarządzanie zapasami, inna za zamawianie dostaw, inna za obsługę klientów, a jeszcze inna za sprzątanie piekarni.

2. Zasada otwartego/zamkniętego

Zasada ta stanowi, że Jednostki oprogramowania (klasy, moduły, funkcje itp.) powinny być otwarte na rozbudowę, ale zamknięte na modyfikację co oznacza, że ​​powinieneś być w stanie rozszerzyć zachowanie klasy, bez modyfikowania go.

Rozumiemy zasadę otwartego/zamkniętego na przykładzie:

Wyobraź sobie, że masz zajęcia o nazwiePaymentProcessor>obsługujący płatności na rzecz sklepu internetowego. PoczątkowoPaymentProcessor>klasa obsługuje tylko przetwarzanie płatności przy użyciu kart kredytowych. Chcesz jednak rozszerzyć jego funkcjonalność również o obsługę płatności za pomocą PayPal.

Zamiast modyfikować istniejącePaymentProcessor>class, aby dodać obsługę PayPal, możesz utworzyć nową klasę o nazwiePayPalPaymentProcessor>która przedłużaPaymentProcessor>klasa. W ten sposóbPaymentProcessor>klasa pozostaje zamknięta na modyfikacje, ale otwarta na rozszerzenie, zgodnie z zasadą otwarte-zamknięte

3. Zasada substytucji Liskova

Zasadę tę wprowadziła Barbara Liskov w 1987 roku i zgodnie z tą zasadą Klasy pochodne lub podrzędne muszą być substytucyjne dla klas podstawowych lub nadrzędnych . Zasada ta zapewnia, że ​​każda klasa będąca dzieckiem klasy nadrzędnej powinna nadawać się do użycia zamiast swojej klasy nadrzędnej bez żadnego nieoczekiwanego zachowania.

Przyjrzyjmy się zasadzie substytucji Liskova na przykładzie:

Jednym z klasycznych przykładów tej zasady jest prostokąt mający cztery boki. Wysokość prostokąta może mieć dowolną wartość, a szerokość może mieć dowolną wartość. Kwadrat to prostokąt o jednakowej szerokości i wysokości. Można więc powiedzieć, że możemy rozszerzyć właściwości klasy prostokąta na klasę kwadratu.

algorytm wyszukiwania binarnego

Aby to zrobić, musisz zamienić klasę podrzędną (kwadratową) z klasą nadrzędną (prostokąt), aby dopasować ją do definicji kwadratu mającego cztery równe boki, ale klasa pochodna nie wpływa na zachowanie klasy nadrzędnej, więc jeśli to zrobisz że naruszy to zasadę substytucji Liskowa.

4. Zasada segregacji interfejsów

Zasada ta jest pierwszą zasadą, która ma zastosowanie do interfejsów zamiast klas w SOLID i jest podobna do zasady pojedynczej odpowiedzialności. Twierdzi, że nie zmuszaj żadnego klienta do implementacji interfejsu, który jest dla niego nieistotny . Tutaj Twoim głównym celem jest skupienie się na unikaniu grubego interfejsu i preferowanie wielu małych interfejsów specyficznych dla klienta. Powinieneś preferować wiele interfejsów klienta zamiast jednego ogólnego, a każdy interfejs powinien mieć określoną odpowiedzialność.

Przyjrzyjmy się zasadzie segregacji interfejsów na przykładzie:

Załóżmy, że wchodzisz do restauracji i jesteś czystym wegetarianinem. Kelner w tej restauracji dał ci kartę menu, która zawiera dania wegetariańskie i niewegetariańskie, napoje i słodycze.

• W takim przypadku jako klient powinieneś posiadać kartę menu, która zawiera wyłącznie pozycje wegetariańskie, a nie wszystko, czego nie spożywasz w swoim jedzeniu. Tutaj menu powinno być inne dla różnych typów klientów.
• Wspólną lub ogólną kartę menu dla wszystkich można podzielić na wiele kart zamiast jednej. Stosowanie tej zasady pomaga w zmniejszeniu skutków ubocznych i częstotliwości wymaganych zmian.

5. Zasada inwersji zależności

Zasada inwersji zależności (DIP) to zasada projektowania obiektowego, która to stwierdza Moduły wysokiego poziomu nie powinny zależeć od modułów niskiego poziomu. Obydwa powinny zależeć od abstrakcji . Dodatkowo abstrakcje nie powinny zależeć od szczegółów. Szczegóły powinny zależeć od abstrakcji.

Unix kontra Windows

• Mówiąc prościej, DIP sugeruje, że klasy powinny opierać się na abstrakcjach (np. Interfejsach lub klasach abstrakcyjnych), a nie na konkretnych implementacjach.
• Pozwala to na bardziej elastyczny i oddzielony kod, ułatwiając zmianę implementacji bez wpływu na inne części bazy kodu.

Przyjrzyjmy się zasadzie inwersji zależności na przykładzie:

W zespole programistów programiści polegają na abstrakcyjnym systemie kontroli wersji (np. Git), aby zarządzać zmianami w bazie kodu i śledzić je. Nie zależą one od konkretnych szczegółów wewnętrznego działania Gita.

Pozwala to programistom skoncentrować się na pisaniu kodu bez konieczności rozumienia zawiłości implementacji kontroli wersji.