Antywzorce Flashcards

Question

Magic number

Answer 1

użycie w kodzie stałych o niewyjaśnionym sensie i pochodzeniu. Przykładem wystąpienia tego antywzorca jest użycie stałej, której nazwa nic nie mówi o jej przeznaczeniu, a komentarze nie wyjaśniają sensu jej użycia. W efekcie tego działania posiadamy w kodzie magiczną liczbę, której przeznaczenia nikt nie zna.

Answer 2

kod, który na skutek używania złożonych struktur językowych (duże zagnieżdżenie instrukcji warunkowych, instrukcje goto itd.) jest nieczytelny i trudny do modyfikacji.

Answer 3

* Boski obiekt * Object * Jo-jo * Anemiczny model dziedziny * Sequential Coupling * Singletonizm

Answer 4

ang. God object: Umieszczenie zbyt wielu funkcji w jednym komponencie (klasie). Obarczenie jej nadmierną odpowiedzialnością, co powoduje problemy w utrzymaniu jej kodu i wyodrębnieniu funkcjonalności.

Answer 5

ang. cesspool: Ponowne wykorzystywanie obiektów, których zachowanie zmienia się przy kolejnym użyciu. Może to być wynikiem braku automatycznego przywracania stanu obiektu przy zwracaniu go do puli obiektów.

Answer 6

ang. Yo-yo problem: Sytuacja, kiedy funkcjonalność jest rozłożona pomiędzy głęboką hierarchię dziedziczących się klas. Aby zrozumieć działanie programu programista musi przechodzić w tę i z powrotem pomiędzy definicjami klas.

Answer 7

ang. Anemic Domain Model: W tym przypadku model dziedziny składa się z klas z atrybutami bez metod, nie jest więc obiektowy.

Answer 8

Klasa wymaga, aby jej metody były wywoływane w określonej kolejności.

Answer 9

ang. Singletonitis: Niepotrzebne używanie wzorca singleton

Answer 10

akronim zaproponowany prze Roberta Martina opisujący pięć podstawowych założeń programowania obiektowego

Answer 11

SRP - Single Responsibility Principle - Zasada jednej odpowiedzialności * Nie powinno być więcej niż jednego powodu do modyfikacji klasy. * Zasada opisana przez Toma DeMarco i Meilira Page-Johnesa – określali ją jedność/spójność (ang. cohese) i definiowali jako funkcjonalność łączącą elementy pojedynczego modułu. * Odpowiedzialność – przyczyna zmiany. Klasa powinna mieć tylko jedną odpowiedzialność (nigdy nie powinien istnieć więcej niż jeden powód do modyfikacji klasy).

Answer 12

OCP - Open-Closed Principle - Zasada otwarte/zamknięte * Składniki oprogramowania (klasy, moduły, funkcje, …) powinny być otwarte na rozbudowę ale zamknięte na modyfikacje. * Zmiany w programie nie powinny pociągać za sobą wprowadzania całej sekwencji modyfikacji w modułach zależnych. Rozbudowa powinna wymagać dodania nowego kodu bez modyfikacji istniejącego. * Jak umożliwić rozbudowę bez modyfikacji kodu? Abstrakcja. * Alternatywnie można użyć wzorca metody szablonowej (Template method).

Answer 13

LSP - Liskov Substitution Principle - Zasada podstawienia Liskov * Musi istnieć możliwość zastępowania typów bazowych ich podtypami. * Barbara Liskov opisała tę zasadę w 1988 roku: „Oczekujemy czegoś na kształt następującej właściwości podstawiania: jeżeli dla każdego obiektu o1 typu S istnieje taki obiekt o2 typu T, że zachowanie wszystkich programów P zdefiniowanych na bazie typu T nie zmienia się, jeśli obiekt o1 zastąpimy obiektem o2, typ S jest podtypem typu T.” * Prostymi słowami: Korzystanie z funkcji klasy bazowej musi być możliwe również w przypadku podstawienia instancji klas pochodnych. * Dziedziczenie jest relacją IS-A (taksonomii, dziedziczenia hierarchicznego). * Obiekt klasy kwadrat nie musi być prostokątem, ponieważ na poziomie zachowania się różnią

Answer 14

ISP - Interface segregation Principle - Zasada segregacji interfejsów * Zasada ma na celu wyeliminowanie nieporęcznych i zbyt rozbudowanych interfejsów. * Do tej grupy zaliczamy nadmiernie rozbudowane i niespójne interfejsy. Należy je podzielić na mniejsze grupy metod. Każda z tych grup będzie odpowiadać za obsługę innego zbioru klientów. Oznacza to, że część klientów będzie korzystała z jednej grupy metod, a pozostałe aplikacje klienckie z pozostałych grup. Wiele dedykowanych interfejsów jest lepsze niż jeden ogólny. Klient nie powinien być zmuszony do zależności od metod, których nie używa

Answer 15

DIP - Depedency Inversion Principle - Zasada odwrócenia zależności * Moduły wysokopoziomowe nie powinny zależeć od modułów niskopoziomowych. Obie grupy modułów powinny zależeć od abstrakcji. * Abstrakcje nie powinny zależeć od szczegółowych rozwiązań. To szczegółowe rozwiązania powinny zależeć od abstrakcji. * Moduły wysokopoziomowe powinny zawierać ważne decyzje strategiczne i modele biznesowe aplikacji. Te moduły w największym stopniu decydują o funkcjonowaniu aplikacji. Jeśli będą zależeć od modułów niskiego poziomu, to zmiany będą wpływać na moduły wysokopoziomowe i wymuszać zmianę działania całej aplikacji.

Answer 16

* Używaj nazw przedstawiających intencje * Unikaj dezinformacji * Twórz nazwy, które da się wymówić * NIE UŻYWAJ notacji węgierskiej (sz, psz, m_) * Im krótszy zakres działania zmiennej tym krótsza zmienna * Im większy zakres działania zmiennej tym dłuższa zmienna * Nazwy publiczne - krótkie * Nazwy prywatne - długie i opisowe

Answer 17

* Rzeczowniki - klasy, interfejsy, zmienne * Czasowniki - metody, funkcje * Przymiotniki – enum * Predykat - zmienne typu boolean, metody zwracające boolean

Answer 18

• Pierwsza zasada konstruowania funkcji: Funkcje powinny być małe • Druga zasada konstruowania funkcji: Funkcje powinny być mniejsze niż są * Ile linii kodu? 4? 10? 20? * Jeśli metoda jest długa to ukrywa wewnątrz klasę * Max 3 argumenty * Metoda ma robić jedną rzecz i robić ją dobrze * Nie przesyłamy zmiennych typu boolean jako argument * Publiczne metody - krótkie nazwy * Prywatne metody - długie opisowe nazwy

Answer 19

• Proces wprowadzania zmian w programie, w wyniku których zasadniczo nie zmienia się funkcjonalność. Celem refaktoryzacji jest więc nie wytwarzanie nowej funkcjonalności, ale utrzymywanie odpowiedniej, wysokiej jakości organizacji systemu. • Wykorzystanie wzorców projektowych: - nowy kod tworzony od zera - modyfikacja istniejącego kodu (refaktoryzacja) • Czym jest refaktoryzacja? - Przekształceniem zmieniającym strukturę kodu nie zmieniającym jego działania. Testy jednostkowe!

Answer 20

``` I: Czytalny kod, czyli formatowanie, nazwy, uproszczenie warunków, jasne etapy procesu II: Ekstrahowanie metod III: SOLID IV: Wzorce projektowe V: Architektura ```

Answer 21

- zwiększenie abstrakcji: - -- enkapsulacja atrybutów (gettery, settery), - -- uogólnianie typów (dzielenie i współużytkowanie kodu), - dzielenie na logiczne części, - wyodrębnianie metod, - mniejsze fragmenty łatwiejsze do zrozumienia, - lepsze nazwy (klas, metod, zmiennych),

Answer 22

- ang. Obfuscation • Sytuacja odwrotna do refaktoringu. • Służy utrudnieniu analizy kodu źródłowego. • NIE ZABEZPIECZA!!! jedynie wymusza użycie większych zasobów

Answer 23

• W związku ze wzrostem złożoności systemów informatycznych nastąpiła potrzeba separacji komponentów. Umożliwia to uproszczenie procedur konfiguracji i zarzadzania (administracji). Zoptymalizowało to również etap syntezy czyli kompozycji całości systemu z oddzielnie projektowanych i dedykowanych elementów. • Warstwy komunikują się ze sobą za pomocą określonego protokołu. - w architekturze warstwowej aplikacji mogą to być interfejsy, klasy abstrakcyjne lub bezpośrednie odwołania do pól i metod - w architekturze warstwowej systemów informatycznych są to najczęściej gniazda sieciowe i pamięć współdzielona

Answer 24

* warstwa logiki biznesowej, * warstwa prezentacji, * warstwa dostępu do danych. * warstwa autentyfikacji i autoryzacji, * warstwa danych (warstwa zarządzania danymi),

Answer 25

* dekompozycja systemu na niezależne komponenty, możliwe do oddzielnej analizy, * łatwość podmiany komponentu z dowolnej warstwy na inny, wykorzystujący ten sam protokół, * możliwość scalenia kolejnych warstw w jedną, z zachowaniem protokołu do następnej i poprzedniej warstwy, * możliwość rozdzielenia jednej warstwy w wiele, z zachowaniem protokołu do następnej i poprzedniej warstwy, * rozdzielenie systemów do zadań dedykowanych, * rozdzielenie mocy obliczeniowej między warstwy, * zapewnienie rozwiązań redundantnych (nadmiarowych, zapasowych).

Answer 26

* trudny do implementacji w istniejących już systemach nie projektowanych z uwzględnieniem modelu warstwowego, * potrzeba obudowania funkcjonalności w dodatkowy interfejs, * utrudnienia związane z zapewnieniem zgodności wstecznej podczas rozbudowy interfejsu.

Answer 27

• MVC (Model View Controller), • HMVC (Hierarhical…), • PAC (Presentation, Abstraction, Control) + wzorce projektowe

Answer 28

* architektura jednowarstwowa (1-tier) * architektura dwuwarstwowa (2-tier) * architektura wielowarstwowa (multi-tier, n-tier)

Answer 29

• samodzielny system lub pojedyncza aplikacja

Answer 30

* program napisany w języku ogólnego przeznaczenia (C#, Python, PHP) komunikujący się z bazą danych (SQL, Oracle) * przeglądarka internetowa współpracująca z serwerem HTTP, oferującym statyczne strony

Answer 31

* przeglądarka internetowa współpracująca z serwerem aplikacji (HTTP ze wsparciem PHP, ASP, JSP, XSQL lub innych narzędzi), korzystającym z bazy SQL - klasyczny model trójwarstwowy, * hierarchiczny system synchronizacji czasu - NTP

Answer 32

* Model – reprezentacja problemu bądź logiki aplikacji * View – odpowiada za wyświetlanie części modelu przez interfejs użytkownika * Controller – odbiera dane wejściowe od użytkownika i na ich podstawie aktualizuje model i odświeża widoki

Answer 33

- kompozyt – tworzenie i praca z zagnieżdżonymi widokami - obserwator – powiadamianie widoku o zmianie modelu - strategia – obsługa reakcji na zdarzenia wejściowe w gestii konkretnych kontrolerów - metoda wytwórcza – domyślny kontroler - dekorator – dynamicznie rozszerza widoki

Answer 34

MTP (model-template-view), MVP (model-view-presenter), HMVC (hierarchical modelview-controller)

Answer 35

• Wzorzec podobny do MVC • PAC - Presentation – formatuje dane graficzne/dźwiękowe - Abstraction – odbiera i przetwarza dane - Control – kontroluje przepływ danych i informacji pomiędzy pozostałymi 2 komponentami • Używany w postaci hierarchicznej struktury agentów. Agenty komunikują się między sobą za pomocą kontrolerów. • W odróżnieniu od MVC prezentacja (widok) i abstrakcja (model) są kompletnie izolowane.

Antywzorce Flashcards

(59 cards)