Czysta architektura

Question 1

Czym cechuje się paradygmat funkcyjny?

Answer 1

• wymusza dyscyplinę bezpośredniego przekazania sterowania (direct transfer)
• kod zawierający funkcje, pętle, if/else if/else

Question 2

Czym cechuje się paradygmat obiektowy?

Answer 2

• wymusza dyscyplinę pośredniego przekazania sterowania (indirect transfer)
• zlikwidował koniecznośc stosowania wskaźników na funkcje dzięki mechanizmowi polimorfizmu

Question 3

Co oznacza pośrednie przekazanie sterowania w paradygmacie obiektowym?

Answer 3

Wywołane odpowiedniej funkcji wirtualnej jest obsługiwane przez mechanizm polimorfizmu. Poprzez wskaźnik na funkcję wywoływana jest odpowiednia funkcja

Question 4

Czym cechuje się paradygmat funkcyjny?

Answer 4

Wymusza dyscyplinę podczas przypisywania wartości (wartości nie mogą się zmienić)

Question 5

Jak paradygmat funkcyjny wspiera używanie współbieżności?

Answer 5

Brak możliwości zmiany wartości zmiennych powoduje brak zakleszczeń, warunków wyścigu, sekcji krytycznych i innych

Question 6

Co to Segregation of mutability?

Answer 6

Podział aplikacji na komponenty zmienne i niezmienne. Komponenty niezmienne wykonują swoje zadania w sposób całkowicie funkcyjny. Komunikują się z komponentami zmiennymi, które dokonują zmian zmiennych

Question 7

Więcej czy mniej kodu w komponentach funkcyjnych?

Answer 7

Radzone jest umieszczać jak najwięcej pracy w komponentach niemodyfikujących zmienne i jednocześnie redukować ilość kodu umieszczanego w komponentach, w których jest to dozwolone

Question 8

Co to Event Sourcing?

Answer 8

Przechowywanie wszystkich zmian stanu zamiast stanu. Sprzyja to paradygmatowi funkcyjnemu. Na przykład zamiast przechowywać obecny stan konta, można przechowywać wszystkie transakcje, których suma da posiadaną kwotę.

Question 9

Jakie są konsekwencje stosowania paradygmatów programowania?

Answer 9

• każdy nakłada na programistę jakąś dodatkową dyscyplinę
• mówią czego nie robić
• każdy paradygmat coś zabiera (np.: goto, wskaźniki na funkcje, przypisania)

Question 10

Czemu dowodzą testy?

Answer 10

Testami dowodzi się niepoprawności programu, a zatem dowodzimy poprawności poprzez porażki w próbach dowiedzenie niepoprawności

Question 11

Charakterystyka Single Responsibility Principle

Answer 11

Każdy moduł powinien odpowiadać (mieć powód do zmiany) tylko przed jednym aktorem

Aktor symbolizuje daną grupę ludzi np.: użytkownicy, udziałowcy)

Przykład: klasa Emplyee z funkcją save (dla bazy danych) i reportHours (dla dziau HR). Interface tej klasy jest zbyt szeroki bo korzysta z niego dwóch aktorów.

Question 12

Czym staje się Single Responsibility Principle na poziomie komponentu?

Answer 12

Common Closure Principle

Question 13

Czym staje się Single Responsibility Principle na poziomie architektury?

Answer 13

Axis of Change

Question 14

Charakterystyka Open Closed Principle

Answer 14

• element oprogramowania powinien być otwarty na rozbudowę, ale zamknięty na modyfikację
• jeżeli komponent A ma być chroniony przed zmianami wprowadzanymi w komponencie B, to komponent B powinien zależeć od komponentu A. Zależność oznacza, że komponent B używa interface komponentu A
• można osiągnąć stosując Single Responsibility Principle i Dependency Inversion Principle

Question 15

Charakterystyka Liskov Substitution Principle

Answer 15

• kod używający interfejsu może być parametryzowany dowolną klasą implementującą ten interfejs
• zachowania specyficzne dla klasy pochodnej zamykać w implementacji interfejsu dzięki czemu uniknie się hardkodowania corner case’ów

Question 16

Charakterystyka Dependency Inversion Principle

Answer 16

• Nie powinny istnieć zależności od niczego konkretnego (wynika z tego, że klasy konkretne powinny pojawiać się wyłącznie we wzorcach kreacyjnych)
• podczas stosowania tej zasady ignorujemy stabilne tło (np.: klasa String)
• unikać zależności od ulotnych implementacji

Question 17

Co powinny dołączać instrukcje takie jak import, using, include?

Answer 17

Powinny dołączać moduły zawierające interfejsy, klasy abstrakcyjne albo inny rodzaj abstrakcyjnej deklaracji

Question 18

Czy można przesłaniać funkcje konkretne?

Answer 18

Nie - dziedziczy się w ten sposób zależności

Question 19

Charakterystyka Interface Segregation Principle

Answer 19

• rozdzielanie większego interfejsu na kilka mniejszych w celu ochrony przed uzaleznianiem się od modułów zawierających więcej niż jest potrzebne
• ograniczony interfejs = mniej powodów do przebudowy w przypadku zmiany

Question 20

Co to jest komponent?

Answer 20

najmniejsza jednostka, którą można zainstalować (np.: plik DLL, libka)

Question 21

Scharakteryzuj REP (Reuse/Release Equivalence Principle)

Answer 21

• “Podstawą ponownego użycia komponentu jest jego numer wydania”
• dostarczać listę zmian/dokumentację każdego wydania
• klasy i moduły zgromadzone w jednym komponencie powinny pozwalać na utworzenie wspólnego wydania
• z punktu widzenia architektury zasada ta oznacza, że klasy i moduły zgrupowane w jeden komponent muszą tworzyć spójną grupę

Question 22

Scharakteryzuj CCP (Common Closure Principle)

Answer 22

W ramach komponentu 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

Question 23

Scharakteryzuj CRP (Common Reuse Principle)

Answer 23

• mówi które klasy nie powinny być grupowane w komponent: klasy, które nie są ściśle powiązane, nie powinny być częścią jednego komponentu
• jeżeli jeden komponent używa drugiego komponentu to tworzona jest zależność między nimi. Jeżeli zmieni się “używany” komponent to trzeba będzie kompilować/instalować takżę “używający” komponent. Powinny zostać złączone w jeden komponent by uniknąć instalacji wielu komponentów.
• jest to uogólniona wersja ISP

Question 24

Które zasady spójności komponentów ze sobą współgrają?

Answer 24

REP i CCP są sprzeczne z CRP. Trzeba znaleźć równowagę w stosowaniu

Question 25

Scharakteryzuj zasadę zależności niecyklicznych (Acyclic Dependencies Principle)

Answer 25

• nie dopuść do powstania cyklicznych związków w diagramie zależności komponentów
• diagram zależności komponentów powinien tworzyć skierowany graf niecykliczny

Question 26

Jak usunąc cykliczność w diagramie zależności komponentów?

Answer 26

• poprzez zastosowanie Dependency Inversion Principle. W komponencie tworzącym cykl wprowadzić użycie interfejsu. Kierunek zależności zostanie odwrócony
• poprzez wydzielenie osobnego komponentu, od którego zależeć będą dwa komponenty z cyklu

Question 27

Scharakteryzuj zasadę stabilnych zależności (Stable Dependencies Principle)

Answer 27

• zależności kierować w stronę elementu stabilnego

Question 28

Czy stabilny komponent powinien zależeć od niestabilnego?

Answer 28

• Żaden stabilny komponent nie powinien zależeć od niestabilnego
• miara stabilności komponentu powinna być większa niż miary stabilności komponentów, od których on zależy. Oznacza to, że miara stabilności powinna zmniejszać się zgodnie z kierunkiem zalezności

Question 29

Co to jest stabilność komponentu?

Answer 29

To ilość pracy jaką trzeba włożyć w zmianę

Question 30

Jak obliczyć miarę stabilność komponentu?

Answer 30

Fan-In - liczba klas spoza naszego komponentu, zależących od klas wewnątrz tego komponentu
Fan-Out - liczba klas w naszym komponencie, zależących od klas spoza tego komponentu

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

Question 31

Jak usunąć miejsce łamiące Stable Dependency Principle?

Answer 31

Stosując Dependency Inversion Principle. Komponent z mniejszą stabilnością zależeć będzie od interfejsu, który jest bardzo stabilny (według książki ma wartość stabilności 1)

Question 32

Scharakteryzuj zasadę stabilnej abstrakcji (Stable Abstraction Principle)

Answer 32

komponent powinien być tak abstrakcyjny jak jest stabilny

Question 33

Jak obliczyć miarę abstrakcji komponentu?

Answer 33

• Nc - liczba klas w komponencie
• Na - liczba klas abstrakcyjnych w komponencie

A = Na / Nc

Question 34

Po co stosować diagram zależności komponentów?

Answer 34

• służy do konserwacji aplikacji. Wraz ze zmianą wymagań i wzrostem rozmiaru kodu wzrasta liczba komponentów. Aktualizacje i monitorowanie diagramu pozwalają znaleźć zależności cykliczne
• izolacja szybkozmiennych elementów od stabilnych

Question 35

Diagram komponentów robić od razu czy wraz z ewolucją projektu?

Answer 35

Na początku projektu nie ma sensu. Struktura zależności komponentów ewoluuje w czasie gdy system się rozrasta i zmienia.

Question 36

Jaki problem może zaistnieć w podeściu Weekly build?

Answer 36

Jeżeli istnieją zależności cykliczne pomiędzy komponentami to czas potrzebny na mergowanie zmian będzie ciągle rósł, pozostawiając coraz mniej czasu na development.

Question 37

Jak rozwiązać “syndrom dnia następnego” przy użyciu diagramu komponentów?

Answer 37

dzielić oprogramowanie na wydawane niezależnie komponenty i wypuszczać releasy z określonym numerem wersji. Zespoły używające takiego komponentu mogą zdecydować czy przejść na nową wersję czy używać poprzedniej.