Najbardziej pojebane wzorce projektowe
III Singleton
Co w nim pojebanego? Jest to jednocześnie wzorzec i antywzorzec. Szczerze nienawidzony przez wszystkich, a jednocześnie w wielu frameworkach z lubością używany (nie w prost, ale zawsze). Do tego jego prawidłowa implementacja w znacznej mierze opiera się o dobrą wolę programisty i zaufanie do użytkownika, że nie będzie grzebał w klasie za pomocą refleksji.
II Constant Class
Wzorzec będący odpowiedzią na antywzorzec Constant Interface. Wszystko fajnie, ale… w sumie nie różni się on w swojej idei singletonu (worek na wspoldzielone wartości), to raz, a dwa po co nam klasa z całym zbiorem stałych skoro można użyć enumów? Może nie będzie to najpiękniejsze rozwiązanie pod słońcem (trzeba „wyczarować” metodę valueOf), ale na pewno lepsze to niż niezbyt bezpieczne typowanie z użyciem popularnych klas (String, Integer, itp.). Co ciekawe można sobie ułatwić życie stosując „combosa” w postaci enuma i statycznego importu. O samych statycznych importach kiedy indziej.
I Chain of responsibility
Dlaczego ten wzorzec uważam za najbardziej pojebany? Z prostej przyczyny jego implementacja jest banalnie prosta, a jednocześnie przysparza ogromnych trudności w utrzymaniu kodu. Szczególnie w Javie gdzie nie ma co liczyć na dynamiczne generowanie i wywoływanie kodu w runtime (wróć… nie jest to trywialne) tak jak to ma miejsce w Ruby czy groovy. Co więcej zdarzyło mi się spotkać implementacje, które dostarczały np. jednego sposobu wywołania, ale z zamienionymi parametrami…
Jak zatem widać jeden z najtrywialniejszych wzorców jakie istnieją może stać się źródłem niezapomnianych przeżyć…