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

Architektura

Architektura oprogramowania to połączenie wysokopoziomowej struktury z niskopoziomowymi szczegółami, relacje między nimi, reguły ich rozbudowywania oraz środowisko pracy. Jej celem jest zminimalizowanie liczby ludzi wymaganych do stworzenia, utrzymywania i rozbudowywania systemu.

Zasady programowania nie zmieniły się od swoich początków. Ciągle używane są te same komendy (np. if’y i while). Są one uniwersalne. Z tego też powodu reguły architektury oprogramowania są uniwersalne i nie zależą od żadnej zmiennej.

Dobra architektura ma następujące zalety:

• Potrzeba niewielu programistów do utrzymania i rozwoju systemu.
• Koszty pracy programistów są minimalizowane.
• Elastyczność i funkcjonalność oprogramowania jest maksymalizowana.
• Łatwo jest wprowadzać zmiany.

Niejednokrotnie programiści dochodzą do wniosku, że muszą przepisać system, ponieważ obecny jest trudny w utrzymaniu i rozwijaniu. Mają przesadną pewność siebie, że teraz, budując od nowa, stworzą idealny system. Po jakimś czasie znowu wpadają w ten sam sposób. Problemem nie jest stary system, lecz nieodpowiednia architektura i praktyki programistyczne. Należy poświęcić im sporo czasu. Pomocne jest w tym zasady SOLID, GRASP, rysowanie diagramów UML, oraz proces TDD.

Systemy mają dwie cechy:

• Zachowanie — system ma zarabiać lub oszczędzać pieniądze.
• Struktura (architektura) – system ma mieć możliwość łatwego zmieniania się i dostosowywania do zmian oczekiwań i jego otoczenia.

W pracy trzeba znaleźć balans między rozwijaniem zachowania (dodawania nowych funkcji) a poprawianiem struktury (ułatwiania rozwijania systemu). Zazwyczaj pilne jest, ale nie ważne, aby nowa funkcja została zaprogramowana. Prace nad strukturą są zaś często ważne, ale nie pilne. Można to przedstawić w macierzy Eisenhowera:

Podczas rozwijania oprogramowania trzeba dodawać wartość do systemu, ale nie można zapominać o poprawianiu jego struktury. Proces refaktoryzacji (usprawniania struktury kodu) musi być ciągły i być codzienną praktyką programistyczną.

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

Źródła

Obrazy

• https://www.pexels.com/photo/light-landmark-building-architecture-135018/

Materiały

• Czysta architektura. Struktura i design oprogramowania. Przewodnik dla profesjonalistów — Robert C. Martin.
• https://pl.wikipedia.org/wiki/SOLID_(programowanie_obiektowe)
• https://pl.wikipedia.org/wiki/Architektura_oprogramowania
• https://architektura-oprogramowania.blogspot.com/p/strona-gowna.html