Wskazówki / porady, jak ograniczyć korzystanie z zajęć „menedżerskich”?

Czasami słyszę, że posiadanie zbyt wielu klas „menedżerskich” w projekcie twojego programu to zapach kodu i niepotrzebna warstwa złożoności. Dla mnie ma sens, że ludzie chcą używać klas menedżerów do manipulowania obiektami i kontrolowania ich z kontekstu, który ma dla nich sens, ale zastanawianie się, jak sprawić, by rozwiązanie działało bez nich, może być mylące.

Czy naprawdę należy unikać zajęć menedżerskich w jak największym stopniu? Jakie artykuły / artykuły powinienem przeczytać o tym, jak wdrożyć alternatywne obejście dla ogólnych / typowych przypadków, w których można usunąć tych menedżerów?

Są może dwa powody, dla których jest to zapach kodu. Jednym z powodów jest to, że może to oznaczać, że nie masz obiektów domeny, ale zamiast tego masz obiekty wartości, które tylko przechowują dane do manipulacji przez klasy kontrolera lub menedżera. Jest to w rzeczywistości dość powszechne i sprowadza się do programowania procedur w języku OO. „Wiele menedżerów” może być wskazówką, że musisz zintegrować logikę stanu, sprawdzanie poprawności i inne bezpośrednie obawy z obiektami domeny, aby faktycznie coś zawierały. Oczywiście istnieją większe wskazówki, takie jak fakt, że nie masz innych metod niż getter / setters.

Innym powodem, dla którego pachnie kodem, jest to, że może to oznaczać, że Twoje obiekty domeny nie odnoszą się do siebie zbyt dobrze. Na przykład, jeśli masz klasę konta, która tak naprawdę nic nie wie o klasie transakcji, poza tym, że nazywa się ona transakcją i może istnieć więcej niż jedna z nich, to znowu nie masz bardzo dynamicznej implementacji domeny biznesowej. Na przykład SavingsAccount może wiedzieć, że nie może zaakceptować transakcji debetowej, jeśli status konta jest zamknięty. Wiele wdrożeń pozostawiłoby to kierownikowi.

Posiadanie wielu klas „menedżerów” jest często objawem anemicznego modelu domeny , w którym logika domeny jest wyciągana z modelu domeny i zamiast tego umieszczana w klasach menedżerów, które mniej więcej odpowiadają skryptom transakcyjnym . Niebezpieczeństwo polega na tym, że w zasadzie powracasz do programowania proceduralnego - które samo w sobie może, ale nie musi być dobrą rzeczą w zależności od twojego projektu - ale faktem, że nie był brany pod uwagę ani zamierzony, jest imo „zapach kodu”.

Zgodnie z zasadą „eksperta ds. Informacji” operacja logiczna powinna znajdować się jak najbliżej wymaganych danych. Oznaczałoby to przeniesienie logiki domeny z powrotem do modelu domeny, dzięki czemu te logiczne operacje mają zauważalny wpływ na stan modelu domeny, a nie skrypty transakcyjne zmieniające stan modelu domeny z zewnątrz.

Największy problem z klasami menedżerskimi polega na tym, że reprezentują one jedynie niejasne wyobrażenie o tym, co klasa powinna zrobić. Jeśli nazwiesz coś Menedżerem, może on zrobić wszystko i wszystko, co możliwe, w związku z tym, czym zarządza. Przypuszczam, że w niektórych kontekstach może to być w porządku, ale powiedziałbym, że w prawie wszystkich przypadkach nie jest to, czego chcesz. Chcesz, aby ktoś mógł spojrzeć na nazwę klasy i nie tylko miał cholerny dobry pomysł na to, co robi klasa, ale także na to, czego ona nie robi.

Innym problemem związanym z klasami menedżerów jest to, że bardzo trudno jest zdecydować, gdzie powinna iść funkcjonalność. Gdy istnieje wiele klas menedżerów, często występuje duże nakładanie się funkcji między klasami menedżerów. Następnie musisz dowiedzieć się, która klasa powinna implementować tę nakładającą się funkcję i oczywiście ktoś inny wybrałby inaczej. Więc kiedy szukają funkcjonalności i nie widzą jej w miejscu, w którym oczekują, to idą do przodu i ponownie ją wdrażają tam, gdzie ich zdaniem należy, ponieważ nie są świadomi istnienia drugiej implementacji. Innymi słowy, klasy menedżerskie prowadzą do trudnych do zrozumienia i często skomplikowanych projektów.