(Anty)wzorce projektowe <- tutaj jest, że anemic domain model to antywzorzec.
Przyznam, że jestem trochę zdziwiony, głównie dlatego, że chyba ostatnio czytałem coś przeciwnego.
Czy nie jest tak, że w ostatnich latach na fali krytyki OOP wypłynął nacisk na to, by jednak trzymać dane i operacje oddzielnie? Co w językach tradycyjnie obiektowych jak C# i Java sprowadza się do podziału klas na worki na dane, pozbawione logiki (czy nie m.in. w celu ułatwienia tego zostały wprowadzone rekordy do C#?) i klasy zawierające metody, ale same nie trzymające danych w inny sposób, jak poprzez operowanie na tych workach na dane. Czyli - o ile rozumiem - dokładnie anemic domain model?
Zdaje się, że to podejście jest też integralną częścią wielu "uznanych", szeroko wykorzystywanych wzorców, takich jak ECS? (Entity Component System - nawet w nazwie już jest wyraźnie zaznaczony podział na worki na dane i logikę)
Nie oznacza to, że trzymanie logiki w klasach (zamiast podejścia proceduralnego, sprowadzającego się do spamowania słowem kluczowym static
) nie wnosi żadnych korzyści: można np. stosować DI oraz budować większą funkcjonalność z mniejszych klocków za pomocą kompozycji (czy nawet - tfu tfu - dziedziczenia)?