(Anty)wzorce projektowe

7

Zbiorczy temat do narzekania na wzorce projektowe, które są antywzorcami, może macie jakieś ulubione? Ode mnie na początek:

  1. Anemic domain model - nieużywanie OOP, tam, gdzie OOP faktycznie pasuje
  2. Specification pattern - takie enterprise if-else, niepotrzebna abstrakcja
  3. Wrappowanie ORM (np. DbContext) i nazywanie tego UoW, w ogólności bezsensowne wrappery, zmniejszające funkcjonalność (raz miałem do czynienia z wrapperem na NHibernate, który wrappował sposób robienia query, tak że dało się zrobić może 1/10 tego co pozwala ISession)
4

Co do Ad 1 to bym dyskutował. Ad 2 - czy masz na myśli https://en.wikipedia.org/wiki/Specification_pattern czy zaszła pomyłka i chodzi o strategię?

Moje ulubione top 3:

  • Kod spaghetti (nie trzeba wyjaśniać) i ogólny syf w kodzie (np. Configuration klasy w Springu takie że nie znajdziesz początku i końca; yaml'e których nikt nie rozumie tydzień po napisaniu; dziwne języki konfiguracji ze słabą dokumentacją ale za to hipsterskie)
  • Napiszmy sami X choć na GitHubie jest już kilka sprawdzonych projektów co robią X
  • Użycie wielowątkowości tam gdzie nie jest koniecznie niezbędna, np. szał sprzed kilku lat z podejściem reactive everything a teraz płacz bo h... wie co się dzieje w kodzie. Użycie Future a potem głowienie się czemu się wyjątek nie zalogował.

Takie wzorce jak Singleton, traktuje teraz jako pryszcz, trzeba wycisnąć (tj. zrefaktorować do czegoś lepszego) i zapomnieć. To co wymieniłem nie da się łatwo naprawić bo często jest skopane od 1 dnia projektu lub z mentalnością zespołu jest coś nie tak.

5

zwykle jest przesada w jedną albo drugą stronę:

  • albo mieszanie wszystkiego razem, totalne spaghetti, kod bardzo uzależniony od iluś specyficznych bibliotek (bez żadnych warstw dodatkowych)
  • albo odwrotnie - czyli wrappowanie wszystkiego i robienie wrapperów na wrappery, i nawet używając potężnych bibliotek z dobrą dokumentacją robi się do tego wrappery, które przestają być tylko wrapperami, a zaczyna być inner platform effect, bo okazuje się, że coraz więcej różnych opcji trzeba zapewnić. I potem wchodząc do takiego projektu zamiast programować w bibliotece X (jak obiecali), pisze się w jakimś wewnętrznym frameworku bez dobrej dokumentacji te same rzeczy, które można by zaimplementować w bibliotece X.
8

OOP - największy buzzword programowania

3

z OOP to:

  • nadużywanie klas (np. w JS niektórzy używają klas jako przestrzeni nazw do programowania proceduralnego. Chyba się w Javie za dużo naprogramowali. Tylko to jest głupie choćby dlatego, że moduły w JS już są taką przestrzenią nazw).
  • niepotrzebne singletony. Zastanawiam się, jaki jest usecase singletona i jedyny sensowny przykład, jaki mi przychodzi do głowy, to leniwe ładowanie zasobów. Czyli mamy obiekt, który musi się połączyć z siecią i pociągnąć jakieś zasoby (które potem sobie zcachuje). Wtedy faktycznie można by zrobić funkcję, która albo ładuje zasoby albo zwraca zcache'owane. Pozostałe przypadki użycia singletona to po prostu zamaskowana zmienna globalna.
  • nadużywanie dziedziczenia (dziedziczenie rzadko jest dobrym pomysłem, a bardzo często ludzie je stosują).
  • niepotrzebne gettery/settery. Czyli ktoś bardzo chciałby traktować obiekty jako worki na dane, ale jednak naczytał się o jakiejś enkapsulacji i próbuje na siłę się wbić w paradygmat, w którym nawet nie pisze w danej chwili.
15
  1. Betonowanie testów, testowanie pojedynczych klas jako rzekomej jednostki, nadmierne mockowanie i przywiązanie do piramidy testów, testowanie crudów jednostkowo.
  2. Nadmierne dziedziczenie
  3. Sterowanie logiki przez wyjątki
  4. Stringly typing - wszystko jest Stringiem
8

Każdy wzorzec, który wymaga wyklepania, wygenerowania pewnej ilości kodu (powiedzmy więcej niż kilka linijek), wg pewnego schematu - tak, że istnieje albo można by do tego zrobić generator w IDE to antywzorzec.
Oczywiście, w niektórych językach się inaczej nie da, ale ludzie nie powinni za często pisać w takich językach.

Moje znienawidzone to mappery i "na grzyba" DTO. Jeśli mamy mappingi 1 do 1 między DTO, a encjami to jest to na grzyba.

1
0xmarcin napisał(a):

@Saalin: ja mam bardzo dobre doświadczenia ze specyfikacją, ale z C# gdzie wzorzec jest wbudowany w Entity Framework a język pozwala na tworzenie drzew AST z wyrażeń. I tam to całkiem dobrze działa bo można mieć invoiceSpec.And(inv => inv.Customer = customerId).And(inv => inv.OrderId = orderId) Wszystko dynamiczne z jednej strony a kompiluje się do SQLa z drugiej...

  1. Miałem na myśli bardziej abstrakcję nad Expression, tak jak tu https://enterprisecraftsmansh[...]ion-pattern-c-implementation/
  2. Nawet jeśli używamy Expression bezpośrednio to też śmierdzi zbliżaniem się do Generic repository i metod w stylu Find(Specification/Expression).
5

Wzorce rozwiązują pewien znany problem w danym kontekście. Bez podania kontekstu dyskusja nie ma sensu. Temat zamykam (;P)

7

My tu rozmawiamy o antywzorcach. W ich przypadku słyszałem definicję: antywzorzec - rozwiązanie które na pierwszy rzut oka wydaje się poprawne ale w dłuższej perspektywie czasu przynosi więcej szkody niż pożytku.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0