Менеджер – це антипаттерн. Якщо у коді проєкта ви бачите якихось *Manager’ів, то це ознака поганого коду та поганого розуміння предметної області (domain).
Порушення принципів TDA (Tell, Don’t Ask), low coupling / high cohesion
Менеджери порушують принцип TDA, в результаті чого об’єкти більше не ізолюють певної відповідальності. Відповідальність стає розмазаною між менеджером та декількома об’єктами, якими він керує. Самі ж об’єкти не ізолюють вирішення певної проблеми, а лише являють собою контейнери для функцій, якими користується *Manager. Об’єкти під менеджером перетворюються на utils-бібліотеки або на втілення anemic domain model, які є визнаними антипатернами.
Порушення TDA автоматично означає порушення іншого принципу – low coupling / high cohesion (слабкої сплутанності / сильної пов’язанності).
Відсутність розуміння Domain Driven Model
Менеджерів використовують тоді, коли предметна область не вивчена і межі об’єктів визначені невірно. Зазвичай термін “Менеджер” відсутній у словарі Ubiquitous Language будь-якої предметної області. Менеджер – це роль користувача системи та/або позиція співробітника у корпоративній ієрархії, але майже ніколи не елемент самої предметної області.
Роздута відповідальність
Зазвичай антипатерн Менеджер має багато спільного з відомим антипатерном – God Object. Самі назви *Manager для одиниць/корпускул обчислень досить розмиті і підштовхують розробників фарширувати їх ще більшою кількістю обчислень, що не пов’язані одне з одним і мають лише те спільне, що використовують ті самі “utils-об’єкти”.
Залишити відповідь