Wzorce projektowe, których należy unikać [zamknięte]

Tym, o co najbardziej martwili się sami autorzy wzorców projektowych, był wzór "Gościa".

Jest to "zło konieczne" - ale jest często nadużywane, a jego potrzeba często ujawnia bardziej fundamentalną wadę w Twoim projekcie.

Alternatywną nazwą dla wzorca "Visitor" jest "Multi-dispatch", ponieważ wzorzec odwiedzający jest tym, co kończy się, gdy chcesz użyć języka oo wysyłki jednego typu, aby wybrać kod do użycia na podstawie typu dwóch (lub więcej) różnych obiektów.

Klasycznym przykładem jest to, że masz przecięcie między dwoma kształtami, ale jest jeszcze prostszy przypadek, który jest często pomijany: porównywanie równości dwóch heterogenicznych obiektów.

W każdym razie, często kończy się z czymś takim:

interface IShape
{
    double intersectWith(Triangle t);
    double intersectWith(Rectangle r);
    double intersectWith(Circle c);
}

Czasami jest to poprawny projekt minimalny - ale przemyśl to. Czy twój projekt naprawdę nakazuje, że musisz wysłać na dwa typy? Czy jesteś gotów napisać każdą kombinatoryczną eksplozję wielu metod?

Często, wprowadzając inną koncepcję, możesz zmniejszyć liczbę kombinacji, które będziesz musiał napisać:

interface IShape
{
    Area getArea();
}

class Area
{
    public double intersectWith(Area otherArea);
    ...
}

Oczywiście to zależy-czasami naprawdę trzeba napisać kod do Obsługa wszystkich tych różnych przypadków-ale warto zrobić przerwę i pomyśleć przed podjęciem decyzji i użyciem Visitor. To może zaoszczędzić Ci wiele bólu później.

Singletons-Klasa używająca Singletona X ma od niej zależność, która jest trudna do zauważenia i trudna do wyizolowania dla testów.

Są używane bardzo często, ponieważ są wygodne i łatwe do zrozumienia, ale mogą naprawdę skomplikować testy.

Zobacz Singletony są patologicznymi kłamcami.

Uważam, że wzór metody szablonowej jest ogólnie bardzo niebezpieczny.

• wiele razy wykorzystuje swoją hierarchię dziedziczenia z "złych powodów".
• klasy bazowe mają tendencję do zaśmiecania się wszelkimi rodzajami niezerelowanego kodu.
Zmusza do zablokowania projektu, często dość wcześnie w procesie rozwoju. (Przedwczesne zablokowanie w wielu przypadkach) Zmiana tego na późniejszym etapie staje się coraz trudniejsza.

Myślę, że nie powinieneś unikać wzorców projektowych (DP), i nie sądzę, że powinieneś zmuszać się do używania DPs przy planowaniu swojej architektury. Powinniśmy używać DPs tylko wtedy, gdy są one naturalne z naszego planowania.

Jeśli Od początku zdefiniujemy, że chcemy użyć danego DP, to na wiele naszych przyszłych decyzji projektowych będzie wpływał ten wybór, bez żadnej gwarancji, że DP, którą wybraliśmy, jest dostosowany do naszych potrzeb.

Jedną rzeczą, której nie powinniśmy robić, to traktować DP jako niezmienną / align = "left" /

Podsumowując, myślę, że nie powinniśmy unikać DPs, powinniśmy je objąć, gdy już nabierają kształtu w naszej architekturze.

Myślę, że Active Record jest nadużywanym wzorcem, który zachęca do mieszania logiki biznesowej z kodem persistance. Nie sprawdza się zbyt dobrze ukrywanie implementacji pamięci masowej z warstwy modelu i powiązanie modeli z bazą danych. Istnieje wiele alternatyw (opisanych w PoEAA), takich jak Table Data Gateway, Row Data Gateway i Data Mapper, które często zapewniają lepsze rozwiązanie i z pewnością pomagają zapewnić lepszą abstrakcję do przechowywania. Również Twój model nie powinien muszą być przechowywane w bazie danych; a co z przechowywaniem ich jako XML lub uzyskiwaniem do nich dostępu za pomocą usług internetowych? Jak łatwo byłoby zmienić mechanizm przechowywania swoich Modeli?

To powiedziawszy, Active Record nie zawsze jest zły i jest idealny do prostszych aplikacji, w których inne opcje byłyby przesadą.

To proste ... unikaj wzorców projektowych, które są niejasne dla Ciebie lub tych, w których nie czujesz się komfortowo .

Aby wymienić niektóre ...

Istnieją pewne niepraktyczne wzory , jak np.:

• Interpreter
• Flyweight

Są też pewne trudniejsze do uchwycenia , np.:

• Abstract Factory - pełny abstrakcyjny wzór fabryczny z rodzinami tworzonych obiektów to nie taka bryza jak się wydaje [25]}
• Bridge - może być zbyt abstrakcyjny, jeśli abstrakcja i implementacja są podzielone na podtypy, ale jest bardzo użyteczny wzorzec w niektórych przypadkach
• Visitor - Mechanizm podwójnej wysyłki jest naprawdę koniecznością.]}

I są pewne wzory, które wyglądają strasznie prosto , ale nie są tak jasnym wyborem z różnych powodów związanych z ich zasadą lub realizacja:

• Singleton - nie do końca zły wzór, po prostu zbyt nadużywany (często tam, gdzie nie jest odpowiedni)
• Observer - świetny wzór ... po prostu sprawia, że kod jest znacznie trudniejszy do odczytania i debugowania]}
• Prototype - kompilator transakcji sprawdza dynamikę (która może być dobra lub zła ... zależy)
• Chain of responsibility - zbyt często po prostu wymuszone / sztucznie wepchnięte w projekt

Dla tych "niepraktycznych", jeden naprawdę warto o tym pomyśleć przed ich użyciem, ponieważ zwykle gdzieś jest bardziej eleganckie rozwiązanie.

• Head First Design Patterns jest koniecznością
• Sourcemaking to "pierwsza pomoc"

Mam nadzieję, że nie dam się za bardzo za to pobić. Christer Ericsson napisał dwa artykuły (Jeden, Dwa) na temat wzorców projektowych w swoim blogu wykrywanie kolizji w czasie rzeczywistym . Jego ton jest dość surowy i może trochę prowokacyjny, ale facet zna się na rzeczy, więc nie lekceważę tego jako rabusiów szaleńca.

Niektórzy mówią, że service locator jest wzorzec anty.

Uważam, że wzorzec obserwatora ma wiele do odpowiedzi, działa w bardzo ogólnych przypadkach, ale gdy systemy stają się bardziej złożone, staje się koszmarem, wymagając powiadomień OnBefore (), OnAfter() i często delegowania zadań asynchronicznych, aby uniknąć ponownego włączenia. Znacznie lepszym rozwiązaniem jest opracowanie systemu automatycznej analizy zależności, który instrumentuje dostęp wszystkich obiektów (z barierami odczytu) podczas obliczeń i automatycznie tworzy krawędź na wykresie zależności.

Uzupełnienie postu Spoike, Refaktoryzacja do wzorców{[2] } to dobra lektura.

Iterator jest jeszcze jednym wzorcem GoF, którego należy unikać, a przynajmniej używać go tylko wtedy, gdy żadna alternatywa nie jest dostępna.

Alternatywy to:

1. Dla-każdej pętli. Ta konstrukcja jest obecna w większości głównych języków i może być używana w celu uniknięcia iteratorów w większości przypadków.

2. Selektory a la LINQ lub jQuery. Powinny być używane, gdy for-each nie jest odpowiednie, ponieważ nie wszystkie obiekty z kontenera powinny być przetwarzane. W przeciwieństwie do iteratorów, selektory pozwala zamanifestować w jednym miejscu, jakiego rodzaju obiekty mają być przetwarzane.