Antywzorce w programowaniu obiektowym

Programowanie obiektowe - czego należy unikać.

Antywzorce w programowaniu obiektowym:

• BaseBean - umieszczanie metod typu utility (użyteczności) w klasie bazowej, a następnie tworzenie klas dziedziczących. Metody utility powinny być wyodrębnione do osobnej biblioteki lub używane przez delegacje, ponieważ są one praktycznie identyczne we wszystkich projektach. Podczas używania dziedziczenia tworzymy niepotrzebne zależności do klasy bazowej, co powoduje utrudnienie kontroli kodu,
• Wołanie przodka (ang. CallSuper) - występuje w przypadku, gdy metoda która nadpisuje metodę z klasy bazowej musi się odwołać do metody bazowej. W takim wypadku należy stworzyć metodę abstrakcyjną a więc metodę bez ciała i implementować ja w klasach dziedziczących,
• Empty subclass failure - złamanie kontraktu klasy nadrzędnej, czyli te same metody z klas pochodnych nie zachowują się tak jak metody z klasy bazowej. Nie spełniają testu Empty Subclass,
• Boski obiekt (ang. God object) - klasa ze zbyt dużą odpowiedzialnością, umieszczenie zbyt dużej ilości metod w jednej klasie,
• Object cesspool - ponowne wykorzystanie obiektu, podczas gdy wcześniej jego zachowanie zostało zmienione,
• Poltergeists - tworzenie obiektów przekazujących tylko i wyłącznie dane dla innych obiektów,
• Jo-jo - zbyt długa hierarchia dziedziczących po sobie klas. Aby zrozumieć program trzeba przechodzić w tę i z powrotem pomiędzy klasami,
• Anemiczny model dziedziny (ang. Anemic Domain Model) - Model dziedziny składa się z klas z atrybutami jednak nie zawierających metod, co powoduje, że nie jest obiektowy. Logika biznesowa przeniesiona jest do innych klas. Rozwiązanie często stosowane, w zależności od przypadku użycia jest traktowane, jako antywzorzec lub poprawne rozwiązanie,
• Sequential Coupling - klasa, która wymaga wywoływania metod w określonej kolejności,
• Singletonizm (ang. Singletonitis) - nadmierne używanie wzorca singleton.

Antywzorce w programowaniu nieobiektowym:

• Accidental complexity – tworzenie nadmiernej złożoności kodu,
• Action at a distance – niespodziewana interakcja pomiędzy odległymi, niepowiązanymi częściami systemu (np. poprzez korzystanie ze zmiennej globalnej),
• Accumulate and fire – wyniki pod procedur zapisywane do zmiennych globalnych,
• Blind faith – niesprawdzenie napisanego kodu,
• Boat anchor – zostawianie nieużywanej od dłuższego czasu części systemu,
• Busy spin – nadmierne zużywanie zasobów CPU przy czekaniu na zdarzenie, użycie np. nieskończonej pętli zamiast obsługi zdarzeń,
• Caching failure – pozostawienie ustawionej flagi istnienia błędu w systemie, podczas gdy błąd już został poprawiony,
• Checking type instead of interface - sprawdzanie typu zamiast interfejsu,
• Coding by exception – obsługa wszystkich nawet niepotrzebnych wyjątków,
• Error hiding – ukrywanie komunikatu o błędzie przed użytkownikiem,
• Sterowanie wyjątkami – implementacji logiki programu poprzez rzucanie odpowiednich wyjątków,
• Hard code – wstawianie do kodu wartości, które mogą być w późniejszym czasie modyfikowalne przez użytkownika,
• Lava flow – wstawianie kodu niskiej jakości, będącego w fazie rozwoju do produkcyjnej wersji systemu,
• Magic number – używanie stałych o niewyjaśnionym zastosowaniu i pochodzeniu. W efekcie tego posiadamy magiczną liczbę (stałą), której nikt nie używa,
• Magic string - nieświadome użycie snippetu (skrótu) przeszkadzające w pisaniu kodu,
• Spaghetti code – kod, który jest trudny do modyfikacji i mało czytelny. Zazwyczaj poprzez używanie rozbudowanych instrukcji warunkowych, instrukcje goto itd.