SOLID, jakie są 5 zasad programowania obiektowego

Solidne figury geometryczne
szkolenie
1

SOLID to akronim odnoszący się do pięciu zasad projektowania obiektowego (OOD lub OOP). Są to wskazówki, z których mogą korzystać programiści, aby tworzyć oprogramowanie, które jest łatwe w zarządzaniu, utrzymaniu i rozszerzaniu. Zrozumienie tych pojęć uczyni cię lepszym programistą i pomoże uniknąć problemów z zarządzaniem oprogramowaniem. Co to znaczy być dobrym programistą?

Każdy, kto ma pewne doświadczenie w programowaniu, ocenia kod oprogramowania napisany przez innych, używając parametrów oceny na podstawie ścieżki kariery.

W swojej karierze zawodowej poznałem wielu programistów i widziałem tysiące linii kodu, a kiedy muszę ocenić umiejętności programisty, zwracam uwagę głównie na dwa czynniki:

  • Prostota w czytaniu kodu;
  • Jakie jest prawdopodobieństwo, że ich kod będzie działał i ewoluował w czasie.

Na szczęście istnieją pewne podstawy lub zasady, które ułatwiają doskonalenie kodowania.

akronim SOLID oznacza:
S: zasada pojedynczej odpowiedzialności
O: zasada otwarta-zamknięta
L: Zasada substytucji Liskova
I: Zasada segregacji interfejsów
D: Zasada odwrócenia zależności

Zacznijmy od zagłębienia się w pierwszą zasadę SOLID, a mianowicie

Zasada pojedynczej odpowiedzialności

Klasa (lub moduł) powinna mieć tylko jeden powód do zmiany, ewolucji.

Sama koncepcja jest bardzo prosta, ale aby osiągnąć tę prostotę, ścieżka implementacji może być bardzo skomplikowana. Klasa powinna mieć tylko jeden powód do zmiany.

Ale dlaczego? 

Dlaczego to takie ważne, aby mieć tylko jeden powód do zmiany?

Na przykład, jeśli istnieją dwa różne powody zmiany, można sobie wyobrazić, że dwa różne zespoły mogłyby pracować nad tym samym kodem z dwóch różnych powodów. Każdy będzie musiał zaimplementować własne rozwiązanie, które w przypadku języka kompilowanego (takiego jak C ++, C # czy Java) może doprowadzić do powstania modułów niekompatybilnych z innymi zespołami lub innymi częściami aplikacji.

Inny przykład: jeśli używasz języka interpretowanego, może być konieczne ponowne przetestowanie tej samej klasy lub modułu z różnych powodów. Oznacza to więcej pracy, czasu i wysiłku na kontrolę jakości.

Identyfikacja jednej cechy, którą powinna mieć klasa lub moduł, jest znacznie bardziej złożona niż zwykłe sprawdzenie listy kontrolnej w celu uruchomienia testów. 

Spróbujmy jednak pomyśleć z mniej technicznego punktu widzenia, czyli spróbujmy przeanalizować użytkownika naszej klasy lub modułu, czyli kto będzie z niej korzystał. Podstawowym aspektem, o którym zawsze musimy pamiętać, jest fakt, że użytkownicy tworzonej przez nas aplikacji lub systemu, którym obsługuje dany moduł, będą żądać modyfikacji w nim. Osoby obsłużone poproszą o zmianę klasy lub modułu. 

Kilka przykładów modułów i ich zastosowania:

  • Moduł obsługi: użytkownik składa się z administratorów baz danych i architektów oprogramowania.
  • Moduł raportowania: użytkownik składa się z pracowników biurowych, księgowych i produkcji.
  • Moduł naliczania opłat dla systemu zarządzania płacami: użytkownicy mogą obejmować prawników, menedżerów i księgowych.
  • Moduł wyszukiwania tekstu dla systemu zarządzania biblioteką: użytkownicy mogą być reprezentowani przez bibliotekarza lub przez gości i klientów samej biblioteki.

Jeśli więc pierwszym krokiem jest wyszukanie aktorów lub aktora pełniącego rolę rozmówcy z modułem, skojarzenie jednostek z wszystkimi rolami może być trudne. W małej firmie jedna osoba może odgrywać wiele ról, podczas gdy w dużej firmie może być wiele osób pełniących jedną rolę. 

Bardziej rozsądne wydaje się identyfikowanie ról niż osób lub użytkowników.

W związku z tym:

  • użytkownik oprogramowania określa przyczyny zmiany;
  • odpowiedzialność to rodzina funkcji, która zaspokaja potrzeby konkretnego aktora, czyli użytkownika systemu;
  • aktorzy, użytkownik staje się źródłem zmian dla rodziny funkcjonalności, które muszą zaspokajać potrzeby użytkownika;
  • ewolucja potrzeb użytkowników napędza ewolucję funkcjonalności;

SOLIDNE zasady

Zobaczmy kilka przykładów

Załóżmy, że mamy klasę Book, która zawiera pojęcie książki i jej funkcjonalności.

class Book {

    function getTitle () {

        powrót „Wielka książka”;

    }

    function getAuthor () {

        powrót „Alessandro Baricco”;

    }

    function nextpage () {

        // Następna strona

    }

    function printCurrent Page () {

        echo „zawartość bieżącej strony”;

    }

}

To bardzo normalne zajęcia. Mamy książkę, a klasa może podać nam tytuł, autora i przejść dalej. Wreszcie jest również w stanie wydrukować bieżącą stronę na ekranie. 

Jest jednak mały problem. 

Myśląc o aktorach zaangażowanych w zarządzanie obiektem Książki, kim mogliby być? 

Możemy tu łatwo pomyśleć o dwóch różnych aktorach: Zarządzanie książkami (jak bibliotekarz) A Mechanizm przekazywania danych (na przykład sposób dostarczania treści do użytkownika: ekranowy, graficzny interfejs użytkownika, tekstowy interfejs użytkownika, może druk). 

Dlatego mamy dwóch bardzo różnych aktorów, którzy wchodzą w interakcję z klasą.

Krótko mówiąc, ta klasa jest mieszanką:

  • logika biznesowa z 
  • prezentacja 

może to stanowić problem, ponieważ narusza zasadę pojedynczej odpowiedzialności (SRP). 

Jak możemy zmienić, jak możemy ulepszyć ten kodeks, aby przestrzegał zasady pojedynczej odpowiedzialności?

Spójrz na następujący kod:

class Book {

    function getTitle () {

        powrót „Oceano Mare”;

    }

    function getAuthor () {

        powrót „Alessandro Baricco”;

    }

    function turn page () {

        // Następna strona

    }

    function getCurrentPage () {

        echo „zawartość bieżącej strony”;

    }

}

interfejs Printer {

    function printPage ($ page);

}

class StampaLibro implementuje Printer {

    function printPages ($ page) {

        echo $ page;

    }

}

 

class HtmlPrinter implementuje Printer {

    function printPages ($ page) {

        Echo ' '. $ page. ' ';

    }

}

Ten bardzo prosty przykład pokazuje, jak oddzielić prezentację od logiki biznesowej i zgodnie z SRP oferuje ogromne korzyści w zakresie elastyczności naszego projektu.

Spójrzmy na inny przykład:

Przykład podobny do powyższego dotyczy sytuacji, w której obiekt może zapisać się i pobrać z prezentacji.

class Book {

    function getTitle () {

        powrót „Oceano Mare”;

    }

    function getAuthor () {

        powrót „Alessandro Baricco”;

    }

    function turn page () {

        // Następna strona

    }

    function getCurrentPage () {

        return "zawartość bieżącej strony";

    }

    function save () {

        $ nazwa_pliku = '/ dokumenty /'. $ this-> getTitolo (). „-”. $ this-> getAuthor ();

        file_put_contents ($ filename, serialize ($ this));

    }

}

Tak jak poprzednio, również tutaj możemy zidentyfikować różnych aktorów Zarządzanie książkami (jak bibliotekarz) A trwałość. Zawsze, gdy chcemy zmienić sposób przechodzenia od strony do strony, musimy zmienić tę klasę. Możemy mieć kilka powodów do zmiany.

class Book {

    function getTitle () {

        powrót „Oceano Mare”;

    }

    function getAuthor () {

        powrót „Alessandro Baricco”;

    }

    function turn page () {

        // Następna strona

    }

    function getCurrentPage () {

        return "zawartość bieżącej strony";

    }

}

class SimpleFilePersistence {

    function save (Book $ book) {

        $ nazwa_pliku = '/ dokumenty /'. $ book-> getTitle (). „-”. $ book-> getAuthor ();

        file_put_contents ($ filename, serialize ($ book));

    }

}

Przeniesienie operacji utrwalania do innej klasy wyraźnie rozdzieli obowiązki i będziemy mogli swobodnie wymieniać metody utrwalania bez wpływu na naszą klasę Book. Na przykład implementacja klasy DatabasePersistence byłaby trywialna, a nasza logika biznesowa zbudowana wokół operacji księgowych nie ulegnie zmianie.

Kontynuuj, czytając drugą zasadę Otwarte / Zamknięte ->

Komentarz 1

Zostaw komentarz

Il tuo email Adres nie sarà pubblicato. I Campi sono obbligatori contrassegnati *

zasada Liskova
szkolenie
Zasada substytucji Liskova, trzecia zasada SOLID

Klasy potomne nigdy nie powinny wpływać na definicje typów klasy nadrzędnej ani zmieniać ich. Koncepcja tej zasady została wprowadzona przez Barbarę Liskov w przemówieniu na konferencji w 1987 roku, a następnie opublikowana w artykule wspólnie z Jannette Wing w 1994 roku. Ich pierwotna definicja…

trendy marketingowe Google
szkolenie
Jak używać Trendów Google do marketingu w czasie rzeczywistym

Jedną z głównych trudności napotkanych przez firmy w 2020 r. Było zrozumienie, w których sektorach produktów należy zdywersyfikować swoją działalność: w rzeczywistości większość sektorów przemysłu doznała poważnych reperkusji, co uniemożliwiło firmom penetrację, zwłaszcza jako nowy gracz. Bardzo niewiele sektorów produkcyjnych ...

strategia analizy biznesowej
metody
Strategie sukcesu Business Intelligence

Budowanie skutecznej strategii Business Intelligence rozpoczyna się od poprawnej wizji celów. Poniżej widzimy kilka podstawowych punktów. Ocena obecnej sytuacji Niedocenianie tego aspektu byłoby poważnym błędem. Ocena aktualnej sytuacji to analiza procesów, struktur ...