Могут ли классы менеджера быть признаком плохой архитектуры?

В последнее время я начал думать, что наличие большого количества руководящих классов в вашем дизайне - это плохо. Идея еще не созрела для меня, чтобы привести убедительные аргументы, но вот несколько общих моментов:

• Я обнаружил, что мне намного сложнее понять системы, которые сильно зависят от «менеджеров». Это связано с тем, что помимо реальных программных компонентов вам также необходимо понять, как и почему используется менеджер.

• Менеджеры, по-видимому, большую часть времени используются для облегчения проблемы с дизайном, например, когда программист не может найти способ сделать программу Just Work ^TM и вынужден полагаться на классы менеджера, чтобы все работало правильно.

Конечно, ясли могут быть хорошими. Очевидный пример - EventManagerодна из моих любимых конструкций всех времен. : P Моя точка зрения заключается в том, что менеджеры, кажется, слишком часто используются, и не по какой-либо уважительной причине, кроме маскировки проблемы с архитектурой программы.

Действительно ли классы менеджера являются признаком плохой архитектуры?

Классы менеджера могут быть признаком плохой архитектуры по нескольким причинам:

• Бессмысленные идентификаторы

  Название FooManagerничего не говорит о том, что на самом деле делает класс , за исключением того, что оно как-то связано с Fooэкземплярами. Если дать классу более осмысленное имя, выясняется его истинное назначение, которое, вероятно, приведет к рефакторингу.

• Дробные обязанности

  Согласно принципу единой ответственности, каждая единица кода должна служить только одной цели. С менеджером вы можете искусственно разделить эту ответственность.

  Рассмотрим ResourceManagerкоординаты времени жизни и доступа к Resourceэкземплярам. У приложения есть единственный, ResourceManagerчерез который оно получает Resourceэкземпляры. В этом случае нет реальной причины, по которой функция ResourceManagerэкземпляра не может обслуживаться статическими методами в Resourceклассе.

• Неструктурированная абстракция

  Часто менеджер вводится для отвлечения основных проблем с объектами, которыми он управляет. Вот почему менеджеры допускают злоупотребления в качестве бинтов для плохо спроектированных систем. Абстракция - это хороший способ упростить сложную систему, но имя «менеджер» не дает представления о структуре абстракции, которую она представляет. Это действительно фабрика, или прокси, или что-то еще?

Конечно, менеджеры могут быть использованы не только для зла, но и по тем же причинам. EventManager-Какой действительно Dispatcher-queues события из источников и передает их заинтересованные мишени. В этом случае имеет смысл разделить ответственность за получение и отправку событий, потому что человек Event- это просто сообщение без понятия происхождения или назначения.

Пишу Dispatcherв Eventслучаях по существу той же самой причине мы пишем GarbageCollectorили Factory:

Менеджер знает, что его полезная нагрузка не должна знать.

Это, я думаю, лучшее оправдание для создания класса, похожего на менеджера. Когда у вас есть некоторый объект «полезной нагрузки», который ведет себя как значение, он должен быть настолько глупым, насколько это возможно, чтобы вся система оставалась гибкой. Чтобы придать смысл отдельным экземплярам, ​​вы создаете менеджера, который осмысленно координирует эти экземпляры. В любой другой ситуации менеджеры не нужны.

Менеджеры могут быть признаком плохой архитектуры, но чаще всего они являются просто признаком неспособности дизайнера придумать более подходящие имена для своих объектов или просто отражением того факта, что английский язык (и любой человеческий язык в этом отношении) подходит для передачи повседневных практических концепций, а не очень абстрактных, высокотехнологичных концепций.

Простой пример, чтобы проиллюстрировать мою точку зрения: до того, как был назван Factory Pattern , люди использовали его, но они не знали, как его назвать. Так, кто-то, кто должен был написать фабрику для своего Fooкласса, возможно, назвал это FooAllocationManager. Это не плохой дизайн, это просто недостаток фантазии.

И затем кто-то должен реализовать класс, который поддерживает множество фабрик и раздает их различным объектам, которые их запрашивают; и он звонит в свой класс, FactoryManagerпотому Industryчто ему никогда не приходило в голову это слово , или он думал, что это будет не круто, потому что он никогда раньше не слышал о чем-то подобном в программировании. Опять же, случай нехватки воображения.

Наличие большого количества классов «менеджера» часто является симптомом анемичной модели предметной области , когда логика предметной области исключается из модели предметной области и вместо этого помещается в классы управляющих, которые более или менее соответствуют сценариям транзакций . Опасность здесь заключается в том, что вы в основном возвращаетесь к процедурному программированию - что само по себе может или не может быть хорошей вещью в зависимости от вашего проекта - но тот факт, что он не был рассмотрен или предназначен, является реальной проблемой imo.

Следуя принципу «эксперта по информации» , логическая операция должна располагаться как можно ближе к необходимым данным. Это означало бы возвращение логики предметной области обратно в модель предметной области, так что именно эти логические операции оказывают заметное влияние на состояние модели предметной области, а не «менеджеры», изменяющие состояние модели предметной области извне.

Краткий ответ: это зависит .

Существует несколько различных форм «классов менеджера», некоторые из них хороши, другие - плохи, и для большинства из них многое зависит от контекста, если введение класса менеджера - правильная вещь. Хорошей отправной точкой для их правильного понимания является следование принципу единой ответственности - если вы точно знаете, за что отвечает каждый класс вашего менеджера (а что нет), у вас будет гораздо меньше проблем с их пониманием.

Или прямо ответить на ваш вопрос: это не количество классов менеджеров, указывающих на плохую архитектуру, но имеющих слишком много из них с неясными обязанностями или имеющих дело со слишком многими проблемами.

Хотя было бы легко сказать, что они по своей сути указывают на плохой дизайн, они могут принести много хорошего и снизить сложность кода и другой шаблонный код по всему проекту, охватывая одну задачу и ответственность повсеместно.

Хотя распространенность менеджеров может быть связана с плохим суждением о дизайне, они также могут справляться с плохими проектными решениями или проблемами несовместимости с другими компонентами в компонентном дизайне или сторонними компонентами пользовательского интерфейса или сторонними веб-сервисами со странным интерфейсом. в качестве примеров.

Эти примеры демонстрируют, где они ужасно полезны в определенных ситуациях для снижения общей сложности и содействия слабой связи между различными компонентами и уровнями путем инкапсуляции «некрасивого кода» в одном месте. Однако, одна проблема состоит в том, что люди считают заманчивым делать Менеджеров одиночными, я бы посоветовал против этого, и, конечно, как и другие предлагали всегда следовать принципу единой ответственности.

Могут ли классы менеджера быть признаком плохой архитектуры?

Вы ответили на свой вопрос: они не должны быть признаком плохого дизайна.

Кроме примера из вашего вопроса с EventManager, есть еще один пример: в шаблоне проектирования MVC презентатор может рассматриваться как менеджер для классов модель / представление.

Однако, если вы неправильно используете концепцию, то это признак плохого дизайна и, возможно, архитектуры.

Когда класс имеет «Менеджер» в названии, берегитесь бог класса проблемы (одна с слишком много обязанностей). Если с помощью своего имени сложно описать, за что отвечает класс, это предупреждающий знак.

За исключением плохих классов менеджера, худшее имя, которое я когда-либо видел, было "DataContainerAdapter"

«Данные» должны быть еще одной из тех запрещенных подстрок в именах - это все данные, «данные» не очень вам говорят в большинстве доменов.

Классы менеджера, как и почти все классы, оканчивающиеся на "-er", являются злыми и не имеют ничего общего с ООП. Так что для меня это признак плохой архитектуры.

Почему? Имя "-er" подразумевает, что дизайнер кода предпринял какое-то действие и преобразовал его в класс. В результате мы имеем искусственную сущность, которая не отражает какую-либо осязаемую концепцию, но выполняет некоторые действия. Это звучит очень процедурно.

Кроме того, обычно такие классы берут некоторые данные и оперируют ими. Это философия пассивных данных и активных процедур, и она нашла свое место в процедурном программировании. Если вы понимаете это, в классах Manager нет ничего плохого, но тогда это не ООП.

Объектное мышление подразумевает, что объекты делают вещи для себя. Откройте для себя свой домен , создайте смысловые сети , пусть ваши объекты будут живыми организмами, умными и ответственными людьми.

Такие объекты не нужно контролировать. Они знают, что делать и как делать. Так что классы менеджера нарушают принципы ООП дважды. Помимо того, что это класс "-er", он управляет другими объектами. Но это зависит от менеджера, хотя. Это он контролирует - он плохой менеджер. Если он координирует - он хороший менеджер. Вот почему буква «С» в MVC должна быть записана как «Координатор».

Правильный ответ на этот вопрос:

1. По-разному.

Каждая ситуация, с которой вы столкнетесь при написании программного обеспечения, отличается. Может быть, вы в команде, где все знают, как классы менеджеров работают внутри? Было бы совершенно безумно не использовать этот дизайн. Или, если вы пытаетесь донести дизайн менеджера до других людей, в этом случае это может быть плохой идеей. Но это зависит от точных деталей.