Podsumowanie projektu: Budowanie czystej architektury

Dzisiaj zakończyłem mini projekt. Pora zatem na podsumowanie i trochę przemyśleń.

Cel projektu

Przerobiłem książkę Czysta Architektura Roberta C. Martina, zrobiłem notatki oraz obejrzałem trochę wykładów o tej architekturze. W najbliższym czasie wykorzystam tę wiedzę w praktyce (w pracy zawodowej). Projekt trochę rozjechał się w czasie — był wymagający intelektualnie oraz przekładanie go na wieczór też nie jest dobrym pomysłem.

Trójkąt projektu

Projekt składa się z trzech elementów (wg teorii trójką projektu): czas, pieniądze i zakres. Omawiam je poniżej.

Budżet

Budżet projektu był 0 zł (oprócz kosztu prądu) i taki udało się zachować. Materiały, z których skorzystałem, były darmowe lub kupione przeze mnie już kiedyś.

Planowałem wykorzystać 26 godzin mojego czasu wolnego. Nie policzyłem, ile dokładnie czasu poświęciłem na ten projekt, szacuję, że jest to około 30 godzin.

Czas

Nie udało mi się realizować tego projektu codziennie. Przez długi czas zbierałem materiały, a dopiero później je przerabiałem. Wiele razy przekładałem ten projekt na piątek lub sobotę (to zły pomysł)

Zakres

Stan zadań wygląda następująco:

Zrobiłem wszystkie zadania!

Ocena

Jestem zadowolony z tego projektu. Mam dobre notatki, lepsze pojęcie o tej architekturze. Muszę jeszcze kilka razy przerobić mojego e-booka oraz dodać najważniejsze elementy do Anki, aby pamiętać je na zawsze 🙂

Najważniejsze osiągnięcia

Za najważniejsze osiągnięcia związane z tym projektem uważam:

• e-book
• Zrozumienie czystej architektury.

Przemyślenia

• Muszę codziennie, regularnie i rano pchać taki projekt do przodu.
• Muszę dodawać do takich projektów coś przyjemniejszego — sama ciężka praca zabija entuzjazm i pożera ogromnie dużo energii.

Plany na przyszłość

W kolejnym mini projekcie będę uczył się lepiej zarządzać projektami 🙂

Rozwój

W kolejnych miesiącach będę na przemian rozwijał się w następujących tematach:

• stawanie się ekspertem w obszarze IT i programowania (w ramach projektu: 4 Tygodniowy Ekspert IT),
• stawanie się ekspertem w obszarze zarządzania (w ramach projektu: 4 Tygodniowy Ekspert Zarządzania),
• stawanie się zaawansowanym amatorem w różnych obszarach (nie zawsze amatorem :)) np. szybkie czytanie, sprzedawanie, efektywne komunikowanie (w ramach projektu: 4 Tygodniowy Zaawansowany Amator).

Koniec

Projekt zakończony. Pora na głęboki oddech, chwilę wytchnienia. Jutro rozpoczynam kolejny projekt: Budowanie czystej architektury. Zapraszam do śledzenia moich poczynań!

Wszystkie posty związane z mini projektem: Budowa czystej architektury:

Źródła

Obraz główny

• https://www.pexels.com/photo/person-holding-black-pen-1109541/

• 

  Budowanie Czystej architektury

  Architekturę można budować oraz rozwijać w następujący sposób:

  1. Zdefiniuj wszystkich aktorów systemu oraz przypadków użycia (zgodnie z Zasadą Pojedynczej Odpowiedzialności aktor jest głównym źródłem zmiany)
  2. Rozdziel system ze względu na aktorów oraz zmiany, które mogą powodować. Podziel go tak, aby zmiany wprowadzane ze względu na jednego aktora, nie wpływały na innego aktora.
  3. Połącz komponenty na podstawie zasady zależności: zależności muszą być skierowane w stronę komponentów o wyższym poziomie.
  4. Użyj kompilatora do pilnowania zasad architektury: zrób testy konwencji, etc. Wykorzystaj modyfikatory dostępu i mechanizm hermetyzacji. Rozważ podejście opakowania według komponentów — jest wtedy mniej klas publicznych oraz większa jest hermetyzacja.
  5. Umieść w procesie rozwoju oprogramowania takie wydarzenia: przegląd kodu, rozmowy o architekturze, przegląd architektury, rozmowy o incydentach naruszenia przyjętych zasad architektonicznych.

  Przykład — sklep internetowy

  

  Na podstawie: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 300 — Rysunek 33.2. — Wstępna architektura komponentów

  Powyższy diagram przedstawia architekturę sklepu internetowego.

  Oznaczenia:

  • Podwójne linie to granice architektoniczne.
  • Prostokąty to komponenty.
  • Strzałki z białymi grotami oznaczają relację: dziedziczy / implementuje.
  • Strzałki z czarnymi grotami oznaczają relację: używa.

  Komponenty:

  • Kontrolery otrzymują dane wejściowe.
  • Interaktory przekazują sterowanie.
  • Prezentery formatują dane.
  • Widoki wyświetlają dane.
  • Gateway’a — łączą się z zewnętrznymi systemami (baza danych, płatności).

  Zasady:

  • Architektura podzielona jest ze względu na aktorów (np. Admin)
  • Przepływ sterowania jest od prawej do lewej.
  • Wszystkie strzałki skierowane są zgodnie z zasadą zależności: w stronę komponentów o wyższym poziomie.
  • Wszystkie strzałki z białymi grotami (relacja: dziedziczy / implementuje) skierowane są przeciwnie do przepływu zależności. Wszystkie strzałki z czarnymi grotami (relacja: używa) skierowane są zgodnie z przepływem sterowania. Przepływ zależności jest w stronę komponentów o wyższym poziomie. Zapewnia to zgodność z zasadą otwarte-zamknięte i zabezpiecza komponenty wysokiego poziomu przed zmianą komponentów niskopoziomowych.

  Wszystkie posty związane z mini projektem: Budowa czystej architektury:

  Źródła

  Obrazy

  • https://www.pexels.com/photo/photo-of-people-on-building-under-construction-1117452/

  Materiały

  • Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin.

Czysta architektura

Czysta architektura jest bardzo podobna do innych architektur: Architektury Heksagonalnej, Architektury Portów i Adapterów, DCI (opracowanej przez Jamesa Colliena i Trygve’a Reenskaug’a) oraz BCE (opracowaną przez Ivara Jacobsena).

Powyższe architektury mają ten sam cel. Jest nim oddzielenie od siebie różnych zadań. Osiągają to w ten sam sposób: dzielą oprogramowanie na warstwy i wyróżniają: warstwę biznesową, interfejs użytkownika i interfejs systemowy. Różnią się ona między sobą tylko szczegółami. Wszystkie one mają wspólne następujące charakterystyki:

• Niezależność od frameworków — są one szczegółami implementacyjnymi i traktowane są jak narzędzia.
• Łatwo testowalne — logika biznesowa jest oddzielona od trudno testowalnych elementów (baza danych, interfejs użytkownika), więc łatwo jest ją testować.
• Niezależne od ulotnych elementów — interfejs użytkownika, baza danych i inne często zmieniające się elementy są oddzielone od logiki biznesowej.
• Niezależne od elementów zewnętrznych — logika biznesowa jest niezależna i oddzielona od interfejsów łączących aplikację z zewnętrznymi elementami.

Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 213 — Rysunek 22.1. — Czysta architektura

Czysta architektura składa się z okręgów, które tworzą następujące warstwy, zaczynając od środka (najwyższego poziomu):

• Encje — logika biznesowa — najważniejsze reguły biznesowe (obiekty z metodami i danymi, struktury danych, funkcje).
• Przypadki użycia — wykorzystanie encji przez aplikacje — aplikacyjne reguły biznesowe.
• Adaptery interfejsów — połączenie przypadków użycia z interfejsami systemu i dostosowywanie danych dla obu sąsiednich warstw.
• Frameworki i sterowniki — najbardziej ulotne elementy: interfejs użytkownika, baza danych, zewnętrzne elementy, urządzenia, sieć www, frameworki, biblioteki.

Zasada zależności

Główną zasadą tej architektury jest zasada zależności: zależności muszą wskazywać w kierunku zasad o wyższym poziomie, czyli do wnętrza architektury (środkowy okręg ma najwyższy poziom). Granice okręgów stworzone są tak, że elementy wewnątrz danego okręgu nie wiedzą nic o tym, co jest na zewnątrz ich, np. nazwy, obiekty, dane występujące w zewnętrznych okręgach nie występują w wewnętrznych okręgach.

Wzorzec Skromny obiekt = moduł trudny do testowania + łatwy do testowania

Skromny obiekt jest wzorcem ułatwiającym wykonywanie testów jednostkowych i oddzielanie obszarów trudnych do przetestowania (np. interfejs użytkownika) od obszarów łatwych. Wzorzec robi to poprzez podzielenie kodu na moduły: skromny — zawiera widoki — ma trudne do przetestowania (łatwe operacje, np. przekazanie napisu) i łatwe do przetestowania — zawiera prezentery (sama logika).

Kod obiektów skromnych powinien być maksymalnie prosty: przekazywać dane i sterowanie. Nie powinien przetwarzać danych (modeli widoku), a jedynie wyświetlać to, co dostanie od prezentera. Wydzielenie trudnego kodu (odpowiadającego za przyjmowanie danych i formatowanie danych) do prezentera umożliwia łatwe przetestowanie tych funkcji.

Przykład:

Na ekranie ma zostać wyświetlona na czerwono ujemna wartość salda konta.

Prezenter przygotowuje odpowiednie dane: wartość salda konta, symbol waluty, kolor napisu. Widok w jak najprostszy sposób wykorzystuje te dane do wykonania swojego zadania. Przekazywany jest również napis wyświetlany na przycisku obok salda konta oraz informacja (true/false) o tym, czy przycisk jest aktywny. Widok nie ma żadnej logiki z tym związanej.

Porty zewnętrzne i wewnętrzne

Porty to publiczne interfejsy. Można wyróżnić:

• Porty wewnętrzne — implementowane na zewnątrz komponentu i używane wewnątrz. Na przykład Przypadek użycia potrzebuje zapisać gdzieś dane. Używa on interfejsu zapisu danych, który zaimplementowany jest w zewnętrznym komponencie (implementującym ten interfejs)
• Porty zewnętrzne — implementowane są wewnątrz komponentu i wykorzystywane poza nim. Na przykład Prezenter używa interfejsu zdefiniowanego w Przypadkach użycia oraz implementacji, która też tam się znajduje.

Można to zauważyć w Przykład zastosowania OCP: https://karolbocian.pl/blog/2020/05/28/zasady-solid-w-kontekscie-architektury/

Wszystkie posty związane z mini projektem: Budowa czystej architektury:

Źródła

Obraz główny

• https://www.pexels.com/photo/person-holding-black-pen-1109541/

Obrazy

• https://www.pexels.com/photo/brown-high-rise-concrete-building-2972004/

Materiały

• Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin.
• https://cezarywalenciuk.pl/blog/programing/clean-architecture–jak-budowac-rozwijalne-oprogramowanie
• https://www.admu.pl/architektura/

Zasady i poziomy

Systemy informatyczne są zapisem zasad i reguł przetwarzania danych. Zasady te zgrupowane są w komponenty, komponenty są ze sobą łączone. Należy łączyć komponenty tak, aby stworzyć skierowany graf acykliczny. Wierzchołkami grafu są komponenty, a krawędziami są zależności.

Poziomy

Można zdefiniować pojęcie poziomu komponentu jako jego odległość (i zasad, które zawiera) od punktu wejścia i wyjścia danych, które ma zmieniać. Komponenty odpowiadające za wejście i wyjście danych z systemu mają poziom 0. Poziom dalszych komponentów jest coraz wyższy wraz z rosnącą odległością od wejścia lub wyjścia systemu.

Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 198 — Rysunek 19.2. — Diagram klas przedstawiający lepszą architekturę systemu.

Powyższy rysunek przedstawia program do szyfrowania. Zaproponowana struktura pozwala na oddzielenie reguł niskopoziomowych (komponent wejściowy oraz wyjściowy) od zasad wysokopoziomowych (głównego powodu istnienia aplikacji — szyfrowania). Należy tutaj podkreślić, że komponenty niższego poziomu są skierowane (zależą od) komponentów poziomu wyższego. Dzięki temu łatwo można wykorzystać reguły biznesowe w innym środowisko, np. podmieniając moduł wejścia. Nie trzeba przy tym zmieniać w ogóle modułu odpowiadającego za szyfrowanie. Komponenty niższego poziomu są jak wtyczki: można je łatwo odpiąć i wpiąć coś innego, np. zapisywanie do pliku, zapisywanie do bazy danych, czytanie na głos.

Istotne reguł biznesowe + istotne dane biznesowe = encje

Reguły biznesowe to najważniejsze zasady w organizacji. Pozwalają one zarabiać lub oszczędzać pieniądze nawet wtedy, gdy nie są zaimplementowane w żadnej aplikacji, tylko realizowane są np. manualnie przez ludzi. Są to istotne reguły biznesowe. Potrzebują one danych. Dane wykorzystywane przez istotne reguły biznesowe nazywane są istotnymi danymi biznesowymi. Połączenie istotnych reguł biznesowych (zachowań) z istotnymi danymi biznesowymi (dane) tworzą obiekty, zwane encjami.

Przypadki użycia

Przypadkiem użycia nazywane jest wykorzystanie zautomatyzowanego systemu. Określa on zasady wejścia danych, ich przetwarzania oraz wyjścia.

Przypadki użycia kontrolują encje. Encje nic nie wiedzą o przypadkach użycia. Encje mają najwyższy poziom w architekturze. To od nich wszystko zależy.

Przypadki użycia powinny operować na prostych strukturach danych (na wejściu i wyjściu). Za wszystkie poważne operacje odpowiedzialne są tylko encje.

Krzycząca architektura

Architektura systemu jest środowiskiem umożliwiającym istnienie przypadków użycia. Powinna ona już na pierwszy rzut oka informować, z jakim środowiskiem ma do czynienia programista, np. spojrzenie na architekturę sklepu internetowego powinno od razu informować programistę, że ma do czynienia ze sklepem internetowym. Architektura powinna od razu krzyczeć o tym, jaką aplikację reprezentuje. Pamiętajmy, że frameworki, bazy danych, interfejs użytkownika są tylko szczegółami. Najważniejsze są przypadki użycia. To je powinien zobaczyć programista od razu, kiedy spojrzy na strukturę aplikacji. Skupienie się na przypadkach użycia, a nie na frameworkach, pozwala na bezpieczny rozwój aplikacji przez dziesięciolecia, bez uzależniania się od frameworków, narzędzi i środowisk.

Wszystkie posty związane z mini projektem: Budowa czystej architektury:

Źródła

Obrazy

• https://www.pexels.com/photo/aerial-photo-of-buildings-and-roads-681335/

Materiały

• Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin.

Łączenie komponentów

Tworząc architekturę, należy zastanowić się, w jaki sposób połączyć ze sobą komponenty. Pomocne są w tym następujące zasady:

• Zasada zależności niecyklicznych.
• Zasada stabilnych zależności.
• Zasada stabilnych abstrakcji.

Zasada zależności niecyklicznych

Nie dopuść do powstania cyklicznych związków w diagramie zależności komponentów.

Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 132.

Zmniejsza to zależność jednych komponentów od drugich — sprawia, że nasz komponent zależy od mniejszej liczby komponentów — łatwiej jest go przetestować oraz rozwijać — wystarczy skompilować nasz komponent i zależne od niego. Zależności cykliczne rodzą problemy z równoległym rozwijaniem komponentów przez kilku programistów, koniecznością kompilowania większej liczby komponentów, konieczność integrowania się i testowania integracji z większą liczbą komponentów.

Cykl można usunąć w następujący sposób:

1. Zastosować zasadę DIP — wystawić interfejs w naszym komponencie, aby odwrócić zależność — teraz to ten drugi komponent będzie zależny od naszego.
2. Utworzyć nowy komponent, od którego będziemy zależni my i inny komponent, do którego chcieliśmy dodać kłopotliwy kod.

SDP — Zasada stabilnych zależności (ang. Stable Dependencies Principle)

Zależność kieruj w stronę elementu stabilnego.

Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 139.

Oprogramowanie tworzone na podstawie tej zasady sprawia, że komponenty mające być łatwe do zmodyfikowania, nie zależą od komponentów stabilnych. Komponent stabilny to taki, w którym trzeba wykonać dużo pracy, aby go zmodyfikować (wpływ on na wiele innych komponentów).

Przykład:

• Komponent stabilny — Od naszego komponentu zależą trzy inne (używają naszego komponentu), lecz on sam nie zależy od żadnego innego. Nasz komponent jest odpowiedzialny za pozostałe trzy komponenty. Jest on stabilny (ciężko go zmienić), odpowiedzialny i niezależny. Jego miara I = 0 (o miarach piszę niżej).
• Komponent niestabilny — Od naszego komponentu nic nie zależy (nikt go nie używa), lecz nasz komponent zależy od trzech innych (używa ich). Jest on niestabilny (łatwo go zmienić, bo wystarczy zmienić tylko go, nie trzeba zmieniać innych komponentów), nieodpowiedzialny (nie jest odpowiedzialny za żaden inny komponent) i zależny. Jego miara I = 1. on I = 1.

SAP — Zasada stabilnych abstrakcji (ang. Stable Abstractions Principle)

Komponent powinien być tak abstrakcyjny, jak jest stabilny.

Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 144.

Ta zasada określa relację między stabilnością i abstrakcyjnością. Zasada SDP (Zasada stabilnych zależności) zaleca tworzyć zależności w stronę stabilności, zaś zasada SAP (Zasada stabilnych abstrakcji) określa, że stabilność implikuje w abstrakcji. Z tych zasad mamy zasadę DIP (Zasada odwrócenia zależności) dla komponentów, która zaleca kierować zależności w stronę abstrakcji.

Miara stabilności

Zdefiniujmy miarę niestabilności (ang. Instability):

I = Fan-Out / (Fan-In + Fan-Out),

gdzie:

• I = niestabilność komponentu. I = 1 -> maksymalnie niestabilny, I = 0 -> maksymalnie stabilny.
• Fan-Out = liczba klas w naszym komponencie zależących od klas spoza komponentu.
• Fan-In = liczba klas spoza naszego komponentu zależących od klas z naszego komponentu

Zgodnie z zasadą SDP (Zasada stabilnych zależności) I naszego komponentu powinna być większa, niż miary I komponentów, od których nasz komponent zależy. Miara I powinna zmniejszać się zgodnie z kierunkiem zależności.

Miara abstrakcji

Zdefiniujmy miarę abstrakcji komponentu:

A = Na / Nc,

gdzie:

• A = abstrakcyjność komponentu. A = 0 -> minimalnie abstrakcyjny (nie ma żadnej abstrakcyjnej klasy), A = 1 -> maksymalnie abstrakcyjny (wszystkie klasy są abstrakcyjne).
• Nc — liczba wszystkich klas w komponencie.
• Na — liczba wszystkich klas abstrakcyjnych i interfejsów w komponencie.

Ciąg główny

Warto jest zaobserwować związek między stabilnością (I) oraz abstrakcyjnością (A).

Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 147 — Rysunek 14.13 — Strefy bólu.

Na powyższym obrazku przedstawiono na osiach obie miary: miarę niestabilności oraz abstrakcyjności. Ciąg główny to odcinek łączący punkty (1,0) i (0,1) (I, A). Umieszczenie komponentów w punktach początku i końca ciągu głównego jest najbardziej pożądane. Na rysunku widać również:

• Strefa bólu, czyli maksymalnie konkretne i stabilne komponenty — nie chcemy takich, bo ciężko je zmienić (są sztywne).
• Strefa bezużyteczności, czyli maksymalnie abstrakcyjne komponenty, których nikt nie używa (należy do wyrzucenia).

Bardzo ciężko jest stworzyć komponenty, które będą na początku i końcu ciągu głównego. Warto jest je jednak umieszczać na ciągu głównym, dlatego zdefiniujmy pomocniczą miarę: odległość od ciągu głównego (D):

D = | A + I -1 |,

gdzie:

• D = 1 -> maksymalne oddalenie od ciągu głównego, D = 1 -> jest na ciągu głównym.
• A — miara abstrakcyjności komponentu.
• I — miara niestabilności komponentu.
• D — odległość od ciągu głównego.

Możemy również policzyć średnią oraz odchylenia standardowe naszych komponentów. Jeżeli komponent jest dalej niż odchylenie standardowe od ciągu głównego, to warto mu się przyjrzeć i zrobić refaktoryzację.

Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 149 — Rysunek 14.14 — Wykres punktowy komponentów.

Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 150 — Rysunek 14.15 — Wykres zmian wartości D dla jednego komponentu w czasie.

Możemy też umieszczać wartość D na osi czasu i obserwować jak kolejne działania oddalają lub zbliżają nas do ciągu głównego oraz zareagować, gdy nasz komponent oddali się od niego za bardzo. Należy pamiętać, że struktury zależności komponentów nie da się zaprojektować od początku do końca. Ewoluuje ona w czasie rozrastania się systemu i wciąż zmienia. Warto więc zdefiniować miary i proces ciągłego obserwowania ich, aby reagować, gdy nasza architektura zaczyna odbiegać od naszej wizji.

Wszystkie posty związane z mini projektem: Budowa czystej architektury:

Źródła

Obrazy

• https://www.pexels.com/photo/arachnid-artistic-blur-close-up-276203/

Materiały

• Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin.

Komponenty

Komponenty to najmniejsze wdrożeniowe elementy oprogramowania, które można instalować.

Spójność komponentów

Spójność komponentów oznacza składanie komponentów takich sposób, aby zachowywały one harmonię oraz były jak najbardziej jednolite. W zapewnianiu spójności komponentów pomagają następujące zasady:

• REP — Zasada istotności numeru wydania (ang. Reuse/Release Equivalence Principle).
• CCP — Zasada wspólnego domknięcia (ang. Common Closure Principle).
• CRP — Zasada wspólnego użycia (ang. Common Reuse Principle).

REP — Zasada istotności numeru wydania (ang. Reuse/Release Equivalence Principle)

Podstawą ponownego użycia komponentu jest jego numer wydania.

Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 124.

Elementy komponentu muszą tworzyć spójną całość, mieć wspólny cel lub przeznaczenie. Numer wydania pozwala zgromadzić ten konkretny stan oprogramowania w spójną całość. Numer wydania informuje o zawartości konkretnej wersji komponentu, kompatybilności komponentów, nowych wersjach i zmianach, które wnoszą.

CCP — Zasada wspólnego domknięcia (ang. Common Closure Principle)

W ramach komponenty zgromadź te klasy, które zmieniają się z tego samego powodu i w tym samym czasie. Na różne komponenty rozdziel te klasy, które zmieniają się w różnym czasie i z różnych powodów.

Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 125.

Zmiana w aplikacji jest nieunikniona. Jeżeli taka ma nastąpić, najlepiej byłoby, gdyby dotyczyła tylko jednego komponentu. Można tutaj zauważyć podobieństwo z zasadą SRP — pojedynczej odpowiedzialności. Obie mówią w skrócie: Grupuj w jednym miejscu elementy, które mają ten sam powód zmiany, a rozdzielaj te, które mają wiele powodów do zmiany (element odpowiada przed wieloma aktorami).

CRP — Zasada wspólnego użycia (ang. Common Reuse Principle)

Nie zmuszaj użytkowników komponentu do zależności od rzeczy, których nie potrzebują.

Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 126.

Klasy, które nie są ze sobą ściśle związane, nie powinny być w tym samym komponencie. Można tutaj zauważyć podobieństwo z zasadą ISP — Zasada segregacji interfejsów. Obie mówią w skrócie, aby nie tworzyć zależności od rzeczy, które są nam niepotrzebne.

Diagram napięć dla spójności komponentów

Zasady spójności komponentów:

• REP — Zasada istotności numeru wydania (ang. Reuse/Release Equivalence Principle).
• CCP — Zasada wspólnego domknięcia (ang. Common Closure Principle).
• CRP — Zasada wspólnego użycia (ang. Common Reuse Principle).

Powyższe zasady są ze sobą sprzeczne, ponieważ REP i CCP są włączające (dążą do dołączania elementów do komponentu), a CRP jest wyłączająca (odrzuca elementy z komponentu). Należy szukać balansu między tymi zasadami.

Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 128 — Rysunek 13.1 Diagram napięć między zasadami spójności komponentów

Na powyższym diagramie przedstawione są relacje między wspomnianymi zasadami. Wszystkie komponenty znajdują się w polu określonym przez trójkąt, którego wierzchołkami są omawiane zasady. Umiejscowienie komponentów zmienia się wraz z rozwojem architektury i aplikacji. Zazwyczaj na początku najważniejsza jest łatwość rozwoju systemu, dlatego komponenty znajdują się blisko zasady CCP, a z czasem komponenty przesuwają się w lewą stroną na rzecz lepszych wydań.

Komponenty będące blisko REP i CRP borykają się z problemem zmieniania się przy każdej drobnej zmianie aplikacji. Komponenty będące blisko CCP i REP mają problem tworzenia zbyt często nowych wydań.

Wszystkie posty związane z mini projektem: Budowa czystej architektury:

Źródła

Obrazy

• https://www.pexels.com/photo/ground-group-growth-hands-461049/

Materiały

• Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin.

Zasady SOLID

Dobre oprogramowanie na najniższym poziomie powinno być zgodne z zasadami SOLID. Znajomość tych zasad przyda się również przy projektowaniu całej architektury. Można je bowiem rozszerzyć na komponenty, moduły i paczki.

Poniżej przedstawiam zasady SOLID.

SRP — Zasada pojedynczej odpowiedzialności – (ang. Single Responsibility Principle)

Każdy moduł powinien odpowiadać dokładnie przed jednym aktorem (mieć dokładnie jedną zmian). Należy oddzielać od siebie fragmenty kodu, na który wpływ mają różni aktorzy.

OCP — Zasada otwarte-zamknięte – (ang. Open-Closed Principle)

Fragment oprogramowania powinien być otwarty na rozbudowę, ale zamknięty na modyfikacje.

LSP — Zasada podstawienia Liskov – (ang. Liskov Substitution Principle)

Funkcje, które używają wskaźników lub referencji do klas bazowych, muszą być w stanie używać również obiektów klas dziedziczących po klasach bazowych, bez dokładnej znajomości tych obiektów.

(źródło: https://pl.wikipedia.org/wiki/Zasada_podstawienia_Liskov). Klasy dziedziczące powinny jedynie rozszerzać klasę bazową i nie zmieniać jej działania.

ISP — Zasada segregacji interfejsów – (ang. Interface Segregation Principle)

Wiele dedykowanych interfejsów jest lepsze niż jeden ogólny. (źródło: https://pl.wikipedia.org/wiki/SOLID_(programowanie_obiektowe)). Należy unikać budowania zależności od niepotrzebnych elementów, ponieważ wnosi to niepotrzebne zależności i może powodować nieprzewidziane problemy.

DI — Zasada odwracania zależności – (ang. Dependency Inversion Principle)

Wysokopoziomowe moduły nie powinny zależeć od modułów niskopoziomowych — zależności między nimi powinny wynikać z abstrakcji. (źródło: https://pl.wikipedia.org/wiki/SOLID_(programowanie_obiektowe)). Elastyczny system zbudowany jest w taki sposób, że wszelkie zależności dotyczą abstrakcji, a nie konkretnych elementów. Instrukcje import i using powinny odnosić się do abstrakcji.

Przykład zastosowania zasady SRP

Rozważmy przypadek klasy pracownika (Employee), która liczy czas pracy, jego wynagrodzenie oraz zapisuje te dane w bazie danych. Ma na nią wpływ trzech aktorów: na liczenie czasu pracy wpływ mają kadry, na liczenie wypłaty wpływ ma księgowość, a na zapis do bazy danych wpływ ma dział techniczny. Należy rozdzielić te trzy odpowiedzialności do trzech różnych klas.

Problem 1 – odpowiedzialność

W klasie Employee jest metoda do liczenia godzin pracy pracownika (RegularHours), z której korzysta metoda ReportHours oraz CalculatePay. Jeżeli dział księgowości zechce inaczej liczyć wypłatę pracownika poprzez zmianę sposobu liczenia godzin pracy w metodzie RegularHours, to przez to zmieni się również działanie metody ReportHours. A tego mieliśmy nie zmieniać. Dział kadr, kiedy to odkryje, będzie bardzo zaskoczony. Może on jednak odkryć to dopiero po wielu latach. A to jest duży problem.

Problem 2 – łączenie zmian (mergowanie)

W klasie Employee dwóch programistów jednocześnie zmienia kod z dwóch różnych powodów (ta klasa zależna jest od trzech aktorów) na własnych branchach. Podczas złączenia kodu do głównego brancha mogą natrafić na konflikty oraz złączony kod może nie działać tak, jak się tego od niego oczekuje.

Rozwiązanie

Rozwiązaniem jest wydzielenie z klasy Employee trzech klas, które będą realizowały konkretne działania związane z klasą Employee dla poszczególnych aktorów. Poniższy obrazek prezentuje ten podział.

Źródło strona 85 — Rysunek 7.3 – Trzy klasy nie wiedzą o istnieniu pozostałych.

Można to rozwiązać na dwa sposoby:

Sposób 1: Za pomocą wzorca Fasada. Klasa Employee odpowiada tylko za przekazywanie sterowania do odpowiednich klas. Przedstawia to poniższy obrazek.

Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 86 — Rysunek 7.4 – Wzorzec projektowy Fasada.

Sposób 2: Klasa Employee ma w sobie swoje dane oraz implementacje najważniejszej dla niej metody. Pozostałe metody zaimplementowane są w innych klasach. Przedstawia to poniższy obrazek.

Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 86 — Rysunek 7.4- Najważniejsze metody są w klasie Employee, która jednocześnie służy za fasadę dla mniejszych funkcji.

Przykład zastosowania OCP

Poniższy rysunek przedstawia architekturę aplikacji prezentującej raporty, których dane zapisane są w bazie danych. Najważniejszym komponentem (najwyższego poziomu) jest Interaktor. Zawiera on logikę biznesową. Inne komponenty to moduły peryferyjne. Jest tutaj zaprezentowana hierarchia oparta o poziomy. Interaktor jest poziomy najwyższego (ponieważ zawiera reguły biznesowe) i z tego powodu jest najbardziej chroniony. To od niego zależy cała reszta aplikacji. Należy zauważyć, że wszystkie zależności komponentów skierowane są od najniższego poziomu, do najwyższego (czyli do Interaktora). Warto zaznaczyć, że interfejs FinancialReportRequester służy do ochronienia klasy FinancialReportController przed zbytnią wiedzą o komponencie Interaktor, np. sprawia, że nie ma on wiedzy o klasie FinancialEnitites. Gdyby FinancialReportController wiedział też o FinancialEnitites, to zmiana tej klasy wpływałaby niepotrzebnie na komponent Kontroler. Nie używa on bezpośrednio FinancialEnitites, więc nie powinien go w ogóle znać. Oprócz ochrony Interaktora przed zmianami w komponentach niższego poziomu należy również chronić inne komponenty przed zmianami w komponentach wyższego poziomu poprzez ukrywanie ich szczegółów.

Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 92 — Rysunek 8.2 – Podział zadań na klasy i zgrupowanie ich w komponenty.

Przykład zastosowania DIP

Stosowanie Zasady odwrócenia zależności opiera się na założeniu, że abstrakcje (a z pewnością powinny) są stabilniejsze niż ich implementacja. Tworząc oprogramowanie, warto zastosować się do poniższych wytycznych:

• Nie należy odnosić się do konkretnych (ulotnych) klas.
• Nie należy dziedziczyć po konkretnych (ulotnych) klasach.
• Nie należy nadpisywać metod klas, lecz stworzyć funkcję abstrakcyjną i ją implementować na różne sposoby.
• Nie należy powoływać się na konkretne (ulotne) elementy.

Poniżej przykład podziału komponentów. Czarna linia pokazuje ich podział. Komponent z górnej części rysunku jest abstrakcyjny i zawiera wszystkie wysokopoziomowe reguły biznesowe. Dolna część rysunku przedstawia komponent konkretny, który zawiera szczegóły implementacji. Przepływ sterowania przecina czarną linię w przeciwnym kierunki do zależności w kodzie. Jest tu zastosowana zasada odwrócenia zależności — zależności odwrócone są względem przepływu sterowania.

Źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin. — s. 110 — Rysunek 11.1 Użycie wzorca projektowego fabryka abstrakcyjna w celu ujarzmienia zależności

Wszystkie posty związane z mini projektem: Budowa czystej architektury:

Źródła

Obrazy

• https://www.pexels.com/photo/board-bricks-brickwork-concrete-269063/

Materiały

• Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin.
• https://pl.wikipedia.org/wiki/Zasada_podstawienia_Liskov
• https://pl.wikipedia.org/wiki/SOLID_(programowanie_obiektowe)

Paradygmaty programowania

Paradygmat to zbiór pojęć i teorii, które tworzą daną dyscyplinę. W programowaniu są trzy paradygmaty: programowanie strukturalne, programowanie obiektowe i programowanie funkcyjne. Żaden z nich nie mówi, jak należy programować. Wręcz odwrotnie, każdy z nich ogranicza wolność w programowaniu. Wygląda to następująco (źródło: Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin, ss. 46-47):

• Programowanie strukturalne wymusza dyscyplinę bezpośredniego przekazywania sterowania (unikanie stosowanie instrukcji skoku: goto).
• Programowanie obiektowe wymusza dyscyplinę pośredniego przekazywania sterowania (narzucenie dyscypliny stosowania wskaźników do funkcji).
• Programowanie funkcyjne wymusza dyscyplinę podczas przypisywania wartości (przypisywanie wartości jest bardzo ograniczone).

Programowanie obiektowe pozwala stworzyć projekt opierającego się na koncepcji wtyczek. Możliwe jest to dzięki polimorfizmowi. Koncepcja wtyczek pozwala stworzyć system, w którym moduły wysokopoziomowe są niezależne od modułów niskopoziomowych (wtyczek).

Programowanie funkcyjne likwiduje problem związany z aktualizowaniem przez wiele wątków jednej zmiennej, ponieważ nie ma tam przypisania wartości. Rzeczywistość może być reprezentowana jako seria transakcji zmieniających stan, np. na koncie mamy 0 zł, wpłaciliśmy 1000 zł, wypłaciliśmy 200 zł. Stan konta = 0 + 1000 – 200 – 800 zł. Baza danych, która ma tylko operację Insert i Read, nie ma problemów ze współbieżnością aktualizacji.

Mamy tylko 3 paradygmaty oprogramowania, które powstały bardzo dawno temu. Można wysnuć wniosek, że oprogramowanie nie rozwija się tak gwałtownie, jak nam się wydaje. Jego podstawy są takie same od dziesięcioleci.

Wszystkie posty związane z mini projektem: Budowa czystej architektury:

Źródła

Obrazy

• https://www.pexels.com/photo/close-up-view-of-plasma-256302/

Materiały

• Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin.
• https://pl.wikipedia.org/wiki/Paradygmat
• https://mfiles.pl/pl/index.php/Programowanie_strukturalne