W tym poście opiszę jak ważne skrzypce grają wzorce zarówno architektoniczne jak i projektowe w programowaniu jak i nadmienię antywzorce oraz związane z nimi praktyki. Zapraszam!
Wzorce projektowe
Wzorce projektowe pozwalają nam pisać kod według pewnych już opisanych wytycznych, które zostały przetestowane pod katem pewnych rozwiązań czyli ów mają nam ułatwić pracę i sprawić czy kod stawał się bardziej rozwojowy na zmiany i bardziej przewidywalny niż chaotyczny. Należy mieć na uwadze że niewłaściwe korzystanie ze wzorców może je przerodzić w antywzorce o czym później. Moim zdaniem każdy programista fajnie jakby znał jakieś wzorce, z pewnych na pewno korzysta nieświadomie lecz posługiwanie się nomenklaturą w zespołach daje dużo dla współpracy. Wymienię najważniejsze wzorce i je opiszę po krótce:
Strukturalne
- Singleton - Jedna , zazwyczaj globalna instancja danej klasy (może być anonimowa).
- Fasada - Klasa, która reprezentuje publiczną funkcjonalność jako uproszczony interfejs danego bytu, przy czym ukrywa szczegóły/detale implementacyjne.
Behavioralne
- Strategy - Świetnie zastępuje konstrukty ze switchami a mianowicie pozwala wykonać dane akcje w zależności od podanych właściwości.
Kreacyjne
- Builder - Wzorzec budowniczy, pozwala budować byty za pomocą określonych właściwości podanych choćby w metodach, które stopniowo budują docelowy byt. Używany często testach dla poprawienia czytelności kodu.
- Generator - generowanie serii danych.
Wzorce architektoniczne
Wzorce architektoniczne jak nazwa wskazuje używane są podczas choćby projektowania modelu i sposobu działania aplikacji według tych wytycznych co mamy. Wyróżniamy wiele takich wzorców i podejść do problemów. Dużo z nich jest już starych i używanych od dawna lecz nadal aktualnych i prężnie używanych. Należy pamiętać że podobnie jak poprzednio należy dobierać potrzebne.
- Hexagonal Architecture - Architektura oparta na portach i adapterach. Tutaj każda klasa, która może być użyta jako zapotrzebowanie (po ang. dependency) implementuje pewien interfejs, który pozwala przełączać zewnętrzne zasoby do aplikacji czyli na przykład: port bazy danych może mieć podłączone różne implementacje baz danych.
- MVC - Model View Controller - Czyli powszechnie wykorzystywany wzorzec przy frameworkach na backendzie. Jest to swojego rodzaju must have. Polega na podzieleniu aplikacje na trzy warstwy: Model, gdzie są zawarte read modele, encje czy inne reprezentacje informacji w aplikacji, View czyli reprezentację widoku, gdzie wyświetlane są dane, oraz Controller czyli "głowa" operacji w aplikacji, która operując na danych przekazuje je do widoku.
- MVP - Model - View - Presenter - Dane z modelu przekazywane są do presentera, skąd wędrują do konkretnego widoku. Co oznacza że jeden widok przypada na jednego presentera.
- MVVM - Model - View - View Model - Dane z modelu wędrują do ViewModel'u, który może obsłużyć wiee widoków.
Zagadnienia
- DRY - Dont try yourself - nie powtarzaj się czyli unikaj pisania powtarzalnego kodu i struktur.
- AHA - Avoid Hasty Abstractions - staraj się nie pisać pochopnych abstrakcji, szczególnie na wstępnych etapach projektu ale także w trakcie z uwagi na zmieniające się dynamiczniej pewne sfery aplikacji.
- KISS - Keep it simple stupid - staraj się zachować czytelną i prostą składnię pisanego kodu aby każdy mógł go zrozumieć.
- YAGNI - You aren't gonna need it - Zasada mówiąca o stwarzaniu ryzyka i długu technicznego poprzez pisania nadmiernego kodu, zanim będzie potrzebny lub użyty.
- SCA - Separation of concern - zasada zaleacjąca unikanie dzielenia odpowiedzialności pomiędzy klasami.
- SOLID - Zbiór zagadnień pozwalających uzyskać czysty kod i go utrzymać. Mogą się wykluczać i nie zawsze zaleca się stosowanie każde z nich ale są dosyć gruntowne.
- GRASP - 9 fundamentalnych reguł określających działania w programowaniu obiektowym.
- TDD - Test Driven Development czyli sposób pracy, w którym zaczynamy od testowania wychodząc z pomysłu, starając się przetestować przewidywane warianty działania.
- BDD - Behaviour Driven Development - testujemy na zasadzie czytelnych instrukcji dla biznesu.
- DDD - Domain Driven Design - Projektowanie aplikacji z wykorzystaniem tak zwane ubiquitous language czyli uniwersalnego języka, który umożliwia komunikację pomiędzy ekspertami domenowi a technicznymi oraz biznesem z użyciem tym samych pojęć. Aplikacja w oparciu o projekt domenowy dzieli się na konteksty a każdy kontekst dzieli się na aplikację, infrastrukturę oraz domenę.