Bycie nazywanym solidnym to komplement. Słowo niesie ze sobą pozytywne pojęcia wiarygodności i szacunku. Wszyscy powinniśmy dążyć do tego, aby stać się jednym.

Jeśli jesteś inżynierem oprogramowania lub chcesz nim zostać, masz szczęście, ponieważ istnieje zestaw SOLIDNYCH zasad, które poprowadzą Cię przez drogę.

SOLID to akronim w zawodzie inżyniera oprogramowania. To znaczy:

• Zasada pojedynczej odpowiedzialności
• O zasada zamkniętego pióra
• Zasada substytucji Liskowa
• Zasada segregacji interfejsów
• Zasada inwersji zależności

Przyjrzyjmy się tym zasadom bardziej szczegółowo.

Pojedyncza odpowiedzialność

Każda klasa powinna mieć jedną odpowiedzialność.

Powinien zajmować się EmailServicetylko wysyłaniem e-maili, a nie wysyłaniem e-maili i aktualizowaniem statusu zamówienia.

Klasa Carpowinna dotyczyć tylko samochodów, a nie innych rodzajów pojazdów silnikowych. Jeśli mamy opisać samochód elektryczny, to taka podklasa jak ElectricCarjest bardziej odpowiednia niż przeładowanie Carcharakterystyką samochodu elektrycznego i benzynowego.

Zasada otwórz-zamknij

Moduł powinien być otwarty na rozbudowę, ale zamknięty na modyfikację

Można EmailServicego rozszerzyć, RecallableEmailServicedodając funkcję przypominania do właśnie wysłanego e-maila.

Dodaje funkcje elektryczne bez ElectricCarmodyfikowania wnętrza .Car

Zmiana Liskowa

Podklasy powinny być zastępowalne dla swoich klas bazowych

W kontekście projektowania zorientowanego obiektowo klasa lub metoda, która akceptuje instancję klasy bazowej, powinna być w stanie przyjąć dowolną instancję swojej podklasy.

An OrderServicepowinien być w stanie użyć dowolnej instancji, która jest zgodna z interfejsem, EmailServicenie martwiąc się, że rzeczywista klasa instancji to EmailServicesama lubRecallableEmailService

An UrbanTripPlannerpowinien być w stanie użyć dowolnej instancji , Caraby określić trasę, nie wiedząc, czy reprezentuje ona samochód elektryczny, czy benzynowy.

Segregacja interfejsów

Wiele interfejsów specyficznych dla klienta jest lepszych niż jeden interfejs ogólnego przeznaczenia

Nie OrderServicemusi recallEmail(...). Dlatego zależy to tylko od EmailServicewysyłania e-maili, nieRecallableEmailService

Podobnie an UrbanTripPlannernie potrzebuje recharge(...)metody z EletricCar. To zależy tylko od interfejsu dostarczonego przezCar

Odwrócenie zależności

Polegaj na abstrakcjach. Nie polegaj na konkrecjach.

Mechanizm zależności proceduralnych zaczyna się od góry, stopniowo rozszerza i zależy od konkretnych szczegółów implementacji.

W programowaniu zorientowanym obiektowo zależność jest odwrócona . Większość zależności powinna opierać się na abstrakcjach. A tam, gdzie istnieje implementacja, jej związek z abstrakcją odwraca się . Zamiast bezpośrednio polegać na implementacji, teraz zależy ona od abstrakcji.

Zależy OrderServiceod interfejsu dostarczonego przez, EmailServicea nie od jego implementacji IMAP lub POP.

UrbanTripPlannerZależy od interfejsu dostarczonego przez , a Carnie od implementacji Tesli lub Toyoty

Wniosek

Zbadaliśmy pochodzenie akronimu SOLID, a także przyjrzeliśmy się szczegółowo każdemu z nich z dwoma przypadkami użycia w projektowaniu obiektowym.

Być może w przeszłości stosowałeś się do niektórych z tych zasad, nie wiedząc o tym, ponieważ są to dobre praktyki. Moim zdaniem hermetyzacja jest zgodna z zasadą otwórz-zamknij .

Być może zastosowałeś niektóre z nich, ponieważ tak właśnie jest. Składniowo ElectricCarobiekt zawsze może przejść jako Carparametr, zgodnie z zasadą podstawienia Liskowa . Jeśli korzystałeś z Dependency Injection, to już postępujesz zgodnie z zasadą Dependency Inversion .

Inne zasady wymagają trochę przemyślenia. Zasada pojedynczej odpowiedzialności wymaga dobrego modelu OO, aby metoda/klasa/moduł były czyste i odchudzone. Możesz potrzebować dobrej oceny, aby określić, jak głęboka powinna być segregacja, przestrzegając zasady segregacji interfejsów .

Bibliografia

• Dokument dotyczący zasad projektowania i wzorców projektowych
• Zasady artykułu OOD
• Czysta architektura: przewodnik rzemieślnika po strukturze i projektowaniu oprogramowania
• https://en.wikipedia.org/wiki/SOLID

Inne artykuły z tej serii:

• Zostać SOLIDNYM programistą
• SOLID w działaniu — zasada pojedynczej odpowiedzialności
• SOLID w działaniu — zasada otwarte-zamknięte
• SOLID w działaniu — zasada Liskov Substitution: planowana
• SOLID w działaniu — zasada segregacji interfejsów: zaplanowana
• SOLID w działaniu — zasada Dependency Inversion: planowana

Dziękuję Ci.