Zasady

Przed pracą praktyczną nad kodem postanowiłem napisać kolejny wstęp do wzorców projektowych.

 

 

 

Powszechne zasady projektowe

Istnieje pewna liczba powszechnych zasad projektowych, z którymi szczerze mówiąc spotkałem się zanim jeszcze rozpocząłem swoją przygodę z programowaniem.
Niektóre zasady mogą wydawać się banalne ,ale moim zdaniem nawet początkujący programista powinien ich przestrzegać.
Jeśli myślisz, że się z nimi nie spotkałeś to możesz się zdziwić .Te zasady możesz znać, tylko nie wiedziałeś ,że mają one swoje określone nazwy. 

  • Keep it Simple Stupid(KISS) albo Buzi (Bez Udziwnień Zapisu, Idioto)
    • Celem tej zasady jest utrzymanie kodu, tak by był on prosty i zrozumiały. Unikając jakichkolwiek niepotrzebnych skomplikowanych zapisów.Zasada nie mówi ,że wszystko musi być uproszczone do bólu, mówi by unikać niepotrzebnych udziwnień. Warto o tym pamiętać. W sumie tę zasadę można stosować nie tylko do programowania. Nawet na przykładzie blogu, gdzie nie są ważne różne bajery, czy kolorowe tła, ale fakt ,że zawartość blogu jest czytelna. Moim zdaniem zasada ta ma też zastosowanie w grafice. To ,że coś ma być dobre wcale nie oznacza, że musi też być skomplikowane.
  • Don’t Repeat Yourself (DRY)
    • Zasada mówi o unikaniu powtórzeń w kodzie. Żadna część systemu nie powinna się powtarzać. Czyli jedna rzecz do konkretnego celu powinna znajdować się tylko w jednej lokalizacji. Najprostszym przykładem użycia tej zasady jest np. oddzielenie powtarzającej się części kodu do metody.
  • Tell Don’t Ask
    • Zasada ta jest ściśle dostosowana do hermetyzacji i przydziałów obowiązków
      do ich prawidłowych klas. Zasada mówi o tym, że powinieneś mówić obiektom, jakie akcje mają przeprowadzać, zamiast ich pytać, w jakim stanie znajdują się i na podstawie tej decyzji wykonywać akcje. Pozwala to na skuteczne podzielnie obowiązków pomiędzy obiektami i unikaniu ścisłych powiązań między klasami.
  • You Ani’t Gonna Need It(YAGNI)
    • Celem tej zasady jest umieszczenie w aplikacji funkcjonalności, która jest obowiązkowa i potrzebna, usuwając przy tym inne dodatki, które myślisz ,że mogą być potrzebne. Na przykład TDD (Test-driven Development) przestrzega tej zasady. TDD polega na pisaniu testów, które sprawdzają funkcjonalność danego systemu. Test ten zawiera tylko kod, który sprawdza obecną funkcjonalność systemu.
  • Separation of Concerns
    • Zasada określająca ,że elementy systemu (czyli klasy i metody) powinny mieć rozłączne i osobliwe zastosowanie. Inaczej mówiąc, żaden z elementów nie powinien współdzielić odpowiedzialności z innym elementem. Dzieląc program na poszczególne zadania znacznie zwiększamy szanse na ponowne wykorzystanie kodu i jego konserwację oraz testowanie.

Nie przejmuj się, jeśli nie zrozumiałeś niektórych z tych zasad, ponieważ ja postanowiłem sprawdzić je w praktyce ,a rezultat na pewno umieszczę na blogu.
Następna grupa zasad, na którą spojrzymy to SOLID.

Zasady projektowe S.O.L.I.D

Zasady projektowe SOLID są kolekcją najlepszych praktyk, jakie można stosować w obiektowości. Termin SOLID pochodzi z pierwszych liter z każdej nazwy zasady. Jak się domyślasz jest ich 5.

  • Single Responsibility Principle (SRP)
    • Ta zasada jest zbliżona do “Separation of Concerns”. Zasada mówi ,że każdy obiekt powinien mieć tylko jeden cel i odpowiedzialność. Stosując tę zasadę unikasz problemów z pojedynczymi klasami, które są niczym szwajcarski scyzoryk. Mając do dyspozycji wiele obiektów zwiększasz czytelność i ułatwiasz zarządzanie kodem aplikacji.
  • Open-Closed Principle (OCP)
    • Zasada mówiąca ,że klasa powinna być otwarta na rozbudowę ,ale zamknięta do jej własnej modyfikacji. Czyli do klasy możemy dodać nowe funkcje i rozszerzenia klasy, ale bez zmiany jej wewnętrznego działania. Zasada ta ma uświadomić programiście ,że zmiana istniejących klas wpłynie na działania innych klas zależnych. Co skończy się błędem i rozsypką całego systemu. Prawdziwe rozwiązanie nie tworzy kolejnych problemów.
  • Liskov Substitution Principle (LSP)
    • LSP mówi, że powinieneś być w stanie używać klasy pochodnej w miejsce klasy nadrzędnej i ona zachowuje się w taki sam sposób, bez modyfikacji. Zasada ta jest zgodna z OCP, ponieważ zapewnia ,że klasa pochodna nie ma wpływu na zachowanie klasy nadrzędnej, lub, innymi słowy, klasy pochodne muszą być substytucyjne w stosunku do ich klas bazowych. Mówiąc prościej w hierarchii klas powinno dać się traktować obiekt klas X jak obiekt klas bazowej . Ważna sprawa, gdy się przesłania metody zgodnie z tą zasadą muszą one zachowywać zachowanie polimorficzne.Mam dziwne wrażenie ,że zasada nie zawsze przestrzegana.
  • Interface Segregation Principle (ISP)
    • Zasada ta pilnuje programistę by nie stworzył systemu, w którym nie można dokonać żadnych zmian. Jak sama nazwa wskazuje ta zasada odnosi się do interfejsów. ISP mówi o dzieleniu interfejsów na mniejsze grupy, tak by klasa dziedzicząca po niej, nie miała do dyspozycji niepotrzebnych metod. Klient nie powinien też implementować dużych interfejsów
  • Dependency Inversion Principle (DIP)
    • DIP jest o wyróżnieniu niektórych klas z konkretnych wdrożeń i ich zależnych klas abstrakcyjnych i interfejsów. Zasada promuje ponowne użycie kodu, ponieważ mówi ona ,że części systemu aplikacji nie powinny być ciasno dostosowana do konkretnej implementacji.

Blisko zasady DIP są pojęcia takie jak “Dependency Injection'” i “Inversion of Control”.

Dependency Injection i Inversion of Control

Dependency Injection, czyli wstrzykiwanie zależności - pozwala na stworzenie luźno powiązanego ze sobą systemu. Każdy komponent może być traktowany niczym plugin. Każdy obiekt może mieć wstrzyknięty konstruktor, metodę bądź właściwość.

W Inversion of Control (odwrócenie sterowania) - jak sama nazwa wskazuje polega ona na odwróceniu kontroli jaka zachodzi w proceduralnym programowaniu. Przykładem może być kod usługi do klienta bez określenia jego działania. Kontrola wtedy jest odwrócona a zachowanie klienta sprawia ,że uzyskuje on usługę.

Koniec kolejnego wstępu

W przyszłych wpisach postaram się pokazać więcej szczegółów dotyczących zasady S.O.L.I.D na praktycznych przykładach.