Antywzorce projektowe

Niektórzy nie lubią uczyć się przez antyprzykłady. Mnie się wydaje jednak, że dobry antyprzykład jest lepszy niż stado wątpliwej jakości poprawnych przykładów.

Dlatego też z ciekawością poczytałem dzisiaj o antywzorcach projektowych programowania na Wikipedii. Poniżej cytuję antywzorce które interesują mnie szczególnie czyli związane z projektowaniem i programowaniem.

Z większością z nich się spotkałem, przy czym zadziwia to że sformułowane antywzorce są tak powszechne! Czyżby w programowaniu czaiła się skończona liczba pułapek? 😉

Chciałbym żeby pojawiły się osoby które by przetłumaczyły do końca ten wpis na język polski (podczas edycji artykułu są dostępne angielskie odpowiedniki):

  • Zmiana funkcjonalności, Inwersja abstrakcji (ang. Abstraction inversion): Nie udostępnianie użytkownikom zaimplementowanej funkcjonalności której potrzebują, przez co muszą ją zaimplementować ponownie używając funkcji wyższego poziomu.
  • Niejednoznaczny punkt odniesienia (ang. Ambiguous viewpoint): Obiektowe modele systemu są prezentowane bez wskazania do czego się odnoszą (bez określenia w jakim kontekście są ukazane).
  • 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 spagetti.
  • Blob: zobacz Wszechmocny obiekt
  • Petrochemia (ang. Gas factory): Zbyt skomplikowany, uciążliwie drobiazgowy projekt systemu lub funkcjonalność.
  • Wadliwe wejście (ang. Input kludge): Zachodzi gdy system nie radzi sobie z poprawnymi i niepoprawnymi danymi na wejściu, gdyż ich obsługa nie jest wyspecyfikowana i błędnie zaimplementowana. Często jest tak, że programista nie jest w stanie wykryć takiego błędu, natomiast użytkownik wykrywa go z łatwością przy pierwszym uruchomieniu.
  • Interfejs gigant (ang. Interface bloat): Tworzenie rozbudowanych i ciężkich interfejsów (w sensie diagramu klas) tak, że stają się one ciężkie do implementacji.
  • Magiczny przycisk (ang. Magic pushbutton): Implementowanie zbyt ubogiego interfejsu użytkownika, bez pozwolenia mu na większą ingerencję w działanie programu. Zachodzi najczęściej wtedy, gdy programista najpierw wyklikuje interfejs użytkownika, a później go oprogramowuje. Zazwyczaj kod, który stoi za funkcjonalnością przycisku dotyczy tylko tego przycisku (np. jest napisany w funkcji onClick), jest bardzo rozbudowany i trudno go wykorzystać w innych miejscach intefejsu.
  • Silnie zależne komponenty (ang. Re-Coupling): Wprowadzanie zbyt silnie powiązanych komponentów, klas w systemie.
  • 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.
  • BaseBean: Umieszczanie metod typu utility w klasie bazowej, a następnie tworzenie na jej podstawie klas pochodnych. Prawidłowo używanie metod utility powinno być obsłużone poprzez delegowanie. Użycie dziedziczenia powoduje, że klasy dziedziczące polegają na funkcjonalności klasy bazowej, co może utrudniać kontrolę kodu przez programistę. Klasy typu utility są za to stabilne i podobne do siebie w różnych projektach – można je wyodrębnić w reużywalną bibliotekę.
  • Wołanie przodka (ang. CallSuper): W programowaniu obiektowym możliwe jest dziedziczenie właściwości i zachowania klas bazowych i przedefiniowywanie ich. Często metoda, która przedefiniowuje metodę bazową musi się i tak odwołać do metody bazowej w środku, aby skorzystać z jej funkcjonalności – dużo lepszym pomysłem w takim wypadku jest stworzenie czysto abstrakcyjnej metody w klasie bazowej.
  • Empty subclass failure
  • 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 cesspool
  • Poltergeists
  • 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. Większość praktyk programistycznych (w tym znany artykuł “Inheritance considered harmful“) zaleca stosowanie płytkiej hierarchii dziedziczenia.
  • Anemiczny model dziedziny (ang. Anemic Domain Model): Antywzorzec opisany przez Martina Fowlera. W tym przypadku model dziedziny składa się z klas z atrybutami bez metod, nie jest więc obiektowy. Logika biznesowa przeniesiona jest do innych klas, które transformują klasy dziedziny zmieniając ich stan (stąd nazwa Fowlera: skrypty transakcyjne). Antywzorzec ten przedmiotem wielu dyskusji – znaczna część metodyk tworzenia oprogramowania w Javie (w tym EJB) operuje na takim modelu. Duża część projektantów przenosi też swoje przyzwyczajenia z modelowania baz danych modelując system w ten sposób.
  • Sequential Coupling
  • Singletonitis
  • Accidental complexity
  • Action at a distance
  • Accumulate and fire
  • Blind faith
  • Boat anchor
  • Busy spin
  • Caching failure Pozostawienie ustawionej flagi istnienia błędu w systemie już po obsłużeniu błędnej sytuacji
  • Checking type instead of interface
  • Code momentum
  • Coding by exception
  • Double-checked locking
  • Error hiding Przechwytywanie komunikatu o błędzie w celu ukrycia go przed użytkownikiem
  • Expection Handling 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 poprzez wyrzucenie wyjątku)
  • Hard code
  • Lava flow Sytuacja, w której kod znajdujący się w fazie rozwoju zostaje włączony do produkcyjnej wersji systemu. Dzieje się tak np. w czasie zmian osobowych w zespole (nowa osoba nie jest świadoma tego, że przejmowany kod nie jest jeszcze ukończony). Ten wzorzec nazywa również sytuację, w której prototyp pewnej funkcjonalności (wytworzony np. w celu sprawdzenia technologii) zostaje włączony do systemu w wersji produkcyjnej. Kod ten jest niskiej jakości, nieprzemyślany, źle zaprojektowany. Jego usunięcie (zastąpienie) wymaga dużej pracy.
  • Magic number Użycie w kodzie stałych o niewyjaśnionym sensie i pochodzeniu. Np nazwa stałej nie mówi nic o jej przeznaczeniu, komentarze również nie wyjaśniają sensu użycia danej stałej. W efekcie tego działania posiadamy w kodzie magiczną liczbę, której przeznaczenia nikt nie zna.
  • Magic string
  • Packratting
  • 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.
  • Superboolean logic
  • Copypasteryzm (ang. Copy and paste programming) Zamiast tworzyć ogólne rozwiązania, kopiuje się (i modyfikuje) istniejący kod
  • Programowanie poprzez generowanie permutacji (ang. programming by permutation) Próba rozwiązania problemu poprzez konsekwentne zmiany w kodzie (bez przemyślenia sprawy i zrozumienia problemu), do czasu aż program zadziała.
  • De-factoring
  • 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
  • Improbability factor
  • Niedojrzała optymalizacja (ang. premature optimization) Optymalizacja na podstawie niedostatecznego zbioru danych
  • Ponowne odkrywanie koła (ang Reinventing the wheel)
  • 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ć.
  • Tester Driven Development
Czytaj podobne  Dwie rzeczy, które warto wiedzieć o serializacji w C#

A teraz zadanie na koniec: przeczytaj tą listę i napisz w komentarzach z iloma z tych antywzorców miałeś do czynienia w trakcie swojej przygody z programowaniem 😉

Przeczytaj też

Najlepsza książka do Pythona Nie wiesz, z jakiej książki/ebooka uczyć się programowania w języku Python? Postanowiłem zrobić zestawienie 10 książek z Heliona na ten temat, abyś mó...
Komplet 28 ebooków i kursów, aby zostać programist... Od jakiegoś czasu dostaję zapytania na temat tego jakie książki, kursy i ebooki polecam. W związku z tym postanowiłem przygotować dzisiaj zestaw, któr...
120 tapet programistycznych za darmo do pobrania Trochę mi się nudziło, więc przygotowałem zestaw 120 tapet dla programistów. Możesz go pobrać. Tapety są w rozdzielczości 1366x768. Podzielone ...
10 fiszek do nauki programowania w Pythonie Uczysz się programowania w Pythonie? Pobierz te 10 fiszek, które ułatwią Ci zapamiętanie funkcji wbudowanych* w Pythona! Programowanie potrafi ...
Napisano w Kolumna Tagi: , , , , , , , , , , , , , , ,
One comment on “Antywzorce projektowe
  1. Hellix pisze:

    Antywzorce z którymi się wielokrotnie zetknąłem:
    -Złoty młotek 😉
    -Copypasteryzm
    -Spaghetti code
    -Boski obiekt
    -Wadliwe wejście
    -Magiczny przycisk

    Z pozostałymi jak narazie się nie zetknąłem, ale myślę że jeszcze niestety wszystko przede mną..:/

Menu