Czysta architektura Flashcards
Czym cechuje się paradygmat funkcyjny?
- wymusza dyscyplinę bezpośredniego przekazania sterowania (direct transfer)
- kod zawierający funkcje, pętle, if/else if/else
Czym cechuje się paradygmat obiektowy?
- wymusza dyscyplinę pośredniego przekazania sterowania (indirect transfer)
- zlikwidował koniecznośc stosowania wskaźników na funkcje dzięki mechanizmowi polimorfizmu
Co oznacza pośrednie przekazanie sterowania w paradygmacie obiektowym?
Wywołane odpowiedniej funkcji wirtualnej jest obsługiwane przez mechanizm polimorfizmu. Poprzez wskaźnik na funkcję wywoływana jest odpowiednia funkcja
Czym cechuje się paradygmat funkcyjny?
Wymusza dyscyplinę podczas przypisywania wartości (wartości nie mogą się zmienić)
Jak paradygmat funkcyjny wspiera używanie współbieżności?
Brak możliwości zmiany wartości zmiennych powoduje brak zakleszczeń, warunków wyścigu, sekcji krytycznych i innych
Co to Segregation of mutability?
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
Więcej czy mniej kodu w komponentach funkcyjnych?
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
Co to Event Sourcing?
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ę.
Jakie są konsekwencje stosowania paradygmatów programowania?
- 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)
Czemu dowodzą testy?
Testami dowodzi się niepoprawności programu, a zatem dowodzimy poprawności poprzez porażki w próbach dowiedzenie niepoprawności
Charakterystyka Single Responsibility Principle
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.
Czym staje się Single Responsibility Principle na poziomie komponentu?
Common Closure Principle
Czym staje się Single Responsibility Principle na poziomie architektury?
Axis of Change
Charakterystyka Open Closed Principle
- 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
Charakterystyka Liskov Substitution Principle
- 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
Charakterystyka Dependency Inversion Principle
- 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
Co powinny dołączać instrukcje takie jak import, using, include?
Powinny dołączać moduły zawierające interfejsy, klasy abstrakcyjne albo inny rodzaj abstrakcyjnej deklaracji
Czy można przesłaniać funkcje konkretne?
Nie - dziedziczy się w ten sposób zależności
Charakterystyka Interface Segregation Principle
- 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
Co to jest komponent?
najmniejsza jednostka, którą można zainstalować (np.: plik DLL, libka)
Scharakteryzuj REP (Reuse/Release Equivalence Principle)
- “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ę
Scharakteryzuj CCP (Common Closure Principle)
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
Scharakteryzuj CRP (Common Reuse Principle)
- 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
Które zasady spójności komponentów ze sobą współgrają?
REP i CCP są sprzeczne z CRP. Trzeba znaleźć równowagę w stosowaniu
