Antywzorce Flashcards
Antywzorce – metodyczne
- Copypasteryzm
- Programowanie przez permutację
- Złoty młotek
- Silver bullet
- Czynnik nieprawdopodobieństwa
- Ponowne odkrywanie koła
- Odkrywanie kwadratowego koła
- U mnie działa
Copypasteryzm
ang. Copy and paste programming – zamiast tworzyć ogólne rozwiązania, kopiuje się (i modyfikuje) istniejący kod
Programowanie przez permutację
ang. programming by permutation – próba rozwiązania problemu przez konsekwentne zmiany w kodzie (bez przemyślenia sprawy i zrozumienia problemu), do czasu aż program zadziała.
Złoty młotek
ang. golden hammer – faworyzowanie jednej technologii w celu rozwiązania wszystkich problemów, również tych, dla których istnieją znacznie lepsze metody.
Silver bullet
założenie, że sprawdzone rozwiązanie techniczne musi być zawsze skuteczne przy rozwiązaniu znacznie większego problemu
Czynnik nieprawdopodobieństwa
ang. improbability factor – założenie, że nie jest prawdopodobne, aby znany błąd się ujawnił w działaniu
Ponowne odkrywanie koła
ang. Reinventing the wheel – rozwiązywanie na nowo problemu dla którego jest już optymalne rozwiązanie.
Odkrywanie kwadratowego koła
ang. Reinventing the square wheel) – rozwiązywanie problemu w zły sposób, podczas gdy istnieją skuteczne i sprawdzone rozwiązania. Na przykład tworzenie własnego systemu bazodanowego, zamiast wykorzystania istniejących darmowych rozwiązań, z dużym prawdopodobieństwem lepszych niż sami jesteśmy w stanie stworzyć.
U mnie działa
ignorowanie problemu powstałego na pewnej instalacji systemu ponieważ problem ten nie wystąpił na innej instalacji.
Antywzorce – w projektowaniu
- Inwersja abstrakcji
- Błotna bryła
- Petrochemia
- System, który gra i tańczy
- System z wyścigami
Inwersja abstrakcji
ang. Abstraction inversion: Nieudostępnianie użytkownikom zaimplementowanej funkcjonalności, której potrzebują, przez co muszą ją zaimplementować ponownie używając funkcji wyższego poziomu.
Błotna bryła
ang. Big ball of mud: Dotyczy systemu o trudnej do wyodrębnienia i zrozumienia strukturze. Modyfikowanie takiego systemu jest ryzykowne, gdyż nie sposób jest przewidzieć skutków zmian, kod przypomina spaghetti.
Petrochemia
ang. Gas factory: Zbyt skomplikowany, uciążliwie drobiazgowy projekt systemu lub funkcjonalność.
System, który gra i tańczy
ang Stovepipe system: Ciężko serwisowalny system zbudowany z komponentów niepowiązanych ze sobą (funkcjonalnie).
System z wyścigami
Race hazard: System, w którym źle zorganizowano obsługę zdarzeń i jego działanie jest zależne od ich kolejności.
Antywzorce – w programowaniu
- Przypadkowa złożoność
- Akcja na odległość
- Blind faith
- Boat anchor
- Caching failure
- Ukrywanie błędów
- Sterowanie wyjątkami
- Hard code
- Magic number
- Spaghetti code
Przypadkowa złożoność
ang. Accidental complexity – wprowadzanie niepotrzebnej złożoności kodu
Akcja na odległość
Action at a distance – niespodziewana interakcja pomiędzy oddzielonymi częściami systemu (np. poprzez zmienne globalne)
Blind faith
niesprawdzanie rezultatów napisanego kodu
Boat anchor
zachowanie części systemu która już nie jest potrzebna
Caching failure
pozostawienie ustawionej flagi istnienia błędu w systemie już po obsłużeniu błędnej sytuacji
Ukrywanie błędów
ang. Error hiding – przechwytywanie komunikatu o błędzie w celu ukrycia go przed użytkownikiem
Sterowanie wyjątkami
ang. Coding by exception – używanie konstrukcji językowych służących do zarządzania błędami (wyjątkami) w celu implementacji właściwej logiki programu (np. zwracanie wyniku z funkcji przez wyrzucenie wyjątku)
Hard code
wstawianie do kodu programu wartości, które mogłyby być potencjalnie modyfikowalne przez użytkownika
Magic number
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.
Spaghetti code
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.
Antywzorce – w projektowaniu obiektowym
- Boski obiekt
- Object
- Jo-jo
- Anemiczny model dziedziny
- Sequential Coupling
- Singletonizm
Boski obiekt
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.
Object
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.
Jo-jo
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.
Anemiczny model dziedziny
ang. Anemic Domain Model: W tym przypadku model dziedziny składa się z klas z atrybutami bez metod, nie jest więc obiektowy.
Sequential Coupling
Klasa wymaga, aby jej metody były wywoływane w określonej kolejności.
Singletonizm
ang. Singletonitis: Niepotrzebne używanie wzorca singleton
SOLID
akronim zaproponowany prze Roberta Martina opisujący pięć podstawowych założeń programowania obiektowego
S
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).
O
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).
L
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ą
I
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
D
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.
Nazewnictwo
- 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
Części mowy
- Rzeczowniki - klasy, interfejsy, zmienne
- Czasowniki - metody, funkcje
- Przymiotniki – enum
- Predykat - zmienne typu boolean, metody zwracające boolean
Metody (funkcje)
• 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
Refaktoryzacja kodu (wykorzystanie wzorców projektowych)
• 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!
Piramida refaktoryzacji
I: Czytalny kod, czyli formatowanie, nazwy, uproszczenie warunków, jasne etapy procesu II: Ekstrahowanie metod III: SOLID IV: Wzorce projektowe V: Architektura
Refaktoryzacja - co można zrobić
- 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),
Zaciemnianie kodu/obfuskacja
- 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
Model warstwowy aplikacji
• 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
Najczęściej wyodrębniane warstwy:
- warstwa logiki biznesowej,
- warstwa prezentacji,
- warstwa dostępu do danych.
- warstwa autentyfikacji i autoryzacji,
- warstwa danych (warstwa zarządzania danymi),
Zalety modelu warstwowego
- 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).
Wady modelu warstwowego
- 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.
Model warstwowy aplikacji – architektura aplikacji
• MVC (Model View Controller),
• HMVC (Hierarhical…),
• PAC (Presentation, Abstraction, Control)
+ wzorce projektowe
Model warstwowy aplikacji – architektura systemów informatycznych
- architektura jednowarstwowa (1-tier)
- architektura dwuwarstwowa (2-tier)
- architektura wielowarstwowa (multi-tier, n-tier)
Architektura jednowarstwowa (1-tier)
• samodzielny system lub pojedyncza aplikacja
Architektura dwuwarstwowa (2-tier)
- 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
Architektura wielowarstwowa (multi-tier, n-tier)
- 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
Wzorce dla aplikacji webowych - MVC
- 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
MVC - wykorzystane wzorce proste
- 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
MVC - pokrewne wzorce
MTP (model-template-view),
MVP (model-view-presenter),
HMVC (hierarchical modelview-controller)
Wzorce dla aplikacji webowych - PAC
• 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.
