​Powszechne Zasady Projektowe

Istnieje pewna liczba powszechnych zasad projektowych. Niektóre zasady projektowe mogą wydawać się banalne, ale nawet początkujący programista powinien ich przestrzegać. Jeśli sądzisz, że się z nimi nie spotkałeś to możesz się zaskoczyć, na pewno je znasz, tylko nie wiedziałeś, że mają one swoje nazwy.

DRY – Don’t Repeat Yourself (nie powtarzaj się)

Jedna z podstawowych zasad programowania – nie powtarzaj się. Wielokrotne użycie tego samego kodu to podstawa programowania. Ż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. Jeśli jesteś blisko powtórzenia np. chcesz zastosować kopiuj/wklej, seria ifów lub w kodzie występują podobne zachowania pomyśl nad stworzeniem abstrakcji (pętla, wspólny interfejs, funkcja, klasa, jakiś wzorzec projektowy np. Strategia itp.), którą będziesz mógł wielokrotnie wykorzystać.
W zasadzie DRY chodzi również o unikanie powtórzeń czynności, które są wykonywane przez programistów. Takie czynności powinny być robione poprzez generatory kodu lub skrypt automatyzujące pracę.

Plusy zasady

• główną zaletą DRY jest uniknięcie błędów popełnianych w trakcie kopiowania powtarzających się fragmentów kodu.
• lepsza czytelność kodu oraz łatwość w utrzymaniu.
• zmiana implementacji tylko w jednym miejscu.

KISS – Keep it Simple Stupid (niech to będzie możliwie proste)

Nie komplikuj prostych rzeczy. Jest to reguła mówiąca, że nie należy na siłę komplikować prostych rzeczy, aby przykładowo wykorzystać niepotrzebne, niemające zastosowania w danym momencie wzorce projektowe. Celem tej zasady jest utrzymanie kodu, tak by był on tak prosty i zrozumiały jak to tylko możliwe. 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ć. Prostota i unikanie złożoności powinna być priorytetem podczas programowania. Kod powinien być łatwy do odczytania i zrozumienia wymagając do tego jak najmniej wysiłku.

Większość systemów działa najlepiej, gdy polegają na prostocie, a nie na złożoności. Staraj się, aby twój kod podczas analizy nie zmuszał do zbytniego myślenia. Gdy po jakimś czasie wracasz do swojego kodu i nie wiesz co tam się dzieje, to znak, że musisz nad tym popracować, a Twój kod może być prostszy.

YAGNI – You Ani’t Gonna Need It (nie będziesz tego potrzebować)

Celem tej zasady jest umieszczenie w aplikacji funkcjonalności, która jest obowiązkowa i potrzebna teraz w tym momencie, usuwając przy tym inne dodatki, które myślisz ,że mogą być potrzebne w przyszłości. Nie należy patrzeć zbyt daleko w przyszłość, ponieważ po pewnym czasie może się okazać, że tracimy czas na coś, co się nie przyda i w rzeczywistości nie będzie potrzebne.

W trakcie rozwoju projektu praktycznie zawsze zmieniają się założenia, co powoduje, że wcześniejsze koncepcje należy zweryfikować lub całkowicie odrzucić. 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.

Tell Don’t Ask (powiedz nie pytaj)

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.

SoC – Separation of Concerns (separacja zagadnień)

Separacja zagadnień polega na podziale programu na odrębne moduły, które nie pokrywające się funkcjonalnością. Taką budowę programu nazywamy modułową.
Zasada określająca, że elementy systemu 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.

Celem SoC – Separation of Concern jest stworzenie systemu, w którym każda część pełni znaczącą role przy zachowaniu możliwości maksymalnej adaptacji do zmian. SoC nie odnosi się tylko do architektury systemu, ale do różnych zagadnień np. do podziału aplikacji na warstwy (prezentacji, logiki biznesowej, dostępu do danych, bazy danych).

​Zalety separacji

• upraszcza prace grupową, każdy pracownik pracuje nad swoim modułem,
• budowa modułowa pozwala na łatwiejszą rozbudowę systemu,
• poprawia czytelność budowy programu,
• pozwala łatwiej zrozumieć działanie systemu,
• poprawia reużywalność elementów systemu.

​Separation of Concern a Single Responsibility Principle

Separacja zagadnień (SoC) i zasada pojedynczej odpowiedzialności (SRP) wydają się bardzo podobne jednak są pomiędzy nimi pewne różnice.
SRP każe oddzielać każdą funkcjonalność do osobnej klasy, która ma się zajmować tylko jedną rzeczą, natomiast SoC każe dzielić zagadnienie, nie koniecznie program na moduły, które w jak najmniejszym stopniu pokrywają się funkcjonalnością.
W pewnych sytuacjach SoC kłóci się z SRP, należy wtedy wybrać odpowiednie rozwiązanie w zależności od rodzaju problemu. W żadnym przypadku nie istnieje idealne rozwiązanie, dlatego należy wybrać rozwiązanie najlepsze z dostępnych, pasujące do danego problemu który mamy rozwiązać.

​ROT – Rule of Three (reguła trzech) rozwinięcie zasady DRY

Zasada KISS jest ściśle powiązana z zasadą DRY. W niektórych sytuacjach łatwiej jest przekopiować kilka linijek niż stosować regułę DRY. Dlatego została wymyślona kolejna zasada ROT (Rule of Three).
Zasada ta mówi, że jeśli istnieją 3 kopie tego samego kodu należy zastosować regułę DRY i połączyć kod. Pozwala to uchronić program przed wprowadzaniem zmian w 3 miejscach, co może spowodować duża ilość nowych problemów.