Я иногда слышу, что наличие слишком большого количества классов «менеджера» в дизайне вашей программы - это запах кода и добавляет ненужный уровень сложности. Для меня имеет смысл, что люди хотят использовать классы менеджера для манипулирования объектами и управления ими из контекста, который имеет для них смысл, но выяснение того, как заставить решение работать без них, может сбивать с толку.
Стоит ли действительно избегать занятий менеджера, насколько это возможно? Кроме того, какие статьи / документы я должен прочитать о том, как реализовать альтернативный обходной путь для общих / общих случаев, когда эти менеджеры могут быть удалены?
Ответы:
Возможно, есть две причины, по которым это пахнет кодом. Одна из причин в том, что это может означать, что у вас нет доменных объектов, но вместо этого у вас есть объекты-значения, которые просто хранят данные для манипулирования классами контроллера или менеджера. На самом деле это довольно распространенное явление, и оно сводится к процедурному программированию на языке ОО. «Множество менеджеров» может быть подсказкой, что вам нужно интегрировать логику состояния, валидацию и другие непосредственные задачи в доменные объекты, чтобы они действительно что-то инкапсулировали. Конечно, есть большие подсказки, такие как тот факт, что у вас нет других методов, кроме getter / setters.
Другая причина, по которой запах кода - это то, что ваши доменные объекты не очень хорошо связаны друг с другом. Например, если у вас есть класс Account, который на самом деле ничего не знает о классе Transaction, за исключением того, что он называется Transaction и их может быть больше, чем один, то, опять же, у вас действительно нет очень активной реализации бизнес-домена. Например, SavingsAccount должен знать, что он не может принять транзакцию DebitTransaction, если accountStatus закрыт. Многие реализации оставили бы это на усмотрение менеджера.
источник
Наличие большого количества классов «менеджера» часто является симптомом анемичной модели предметной области , когда логика предметной области исключается из модели предметной области и вместо этого помещается в классы управляющих, которые более или менее соответствуют сценариям транзакций . Опасность здесь заключается в том, что вы в основном возвращаетесь к процедурному программированию - что само по себе может или не может быть хорошей вещью в зависимости от вашего проекта - но тот факт, что он не был рассмотрен или предназначен, является имхо «запаха кода».
Следуя принципу «эксперта по информации» , логическая операция должна располагаться как можно ближе к необходимым данным. Это будет означать перемещение логики домена обратно в модель домена, так что именно эти логические операции оказывают заметное влияние на состояние модели домена, а не сценарии транзакций, изменяющие состояние модели домена извне.
источник
Самая большая проблема с менеджерами классов заключается в том, что они представляют только смутное представление о том, что должен делать класс. Если вы называете что-то менеджером, он может делать все что угодно, что бы он ни делал. Я предполагаю, что в некоторых случаях это может быть хорошо, но я бы сказал, что почти во всех случаях это не то, что вы хотите. Вы хотите, чтобы кто-то мог взглянуть на имя класса и иметь не только чертовски хорошее представление о том, что делает класс, но и о том, что он не делает.
Другая проблема, связанная с классами менеджера, заключается в том, что очень трудно решить, куда должна идти функциональность. Когда имеется много классов менеджера, то часто между функциональными классами менеджера много общего. Затем вы должны выяснить, какой класс должен реализовывать эту перекрывающуюся функциональность, и, конечно, кто-то другой выбрал бы по-другому. Поэтому, когда они ищут функциональность и не видят ее там, где ожидают, тогда они идут дальше и повторно реализуют ее там, где, по их мнению, она принадлежит, потому что они не знают о существовании другой реализации. Другими словами, классы менеджера приводят к трудным для понимания и часто запутанным проектам.
источник