Чи можуть заняття менеджером бути ознакою поганої архітектури?

Останнім часом я почав думати, що мати багато класів менеджерів у своєму дизайні - це погано. Ідея недостатньо дозріла для мене, щоб зробити переконливий аргумент, але ось кілька загальних моментів:

• Мені здалося, що набагато складніше мені зрозуміти системи, які сильно покладаються на "менеджерів". Це тому, що, крім власне компонентів програми, ви також повинні розуміти, як і навіщо використовується менеджер.

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

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

Чи справді класи менеджерів є ознакою поганої архітектури?

Класи менеджерів можуть бути ознакою поганої архітектури з кількох причин:

• Безглузді ідентифікатори

  Назва FooManagerнічого не говорить про те, що насправді робить клас , за винятком того, що воно якось включає Fooекземпляри. Надання класу більш значущої назви з’ясовує його справжню мету, що, ймовірно, призведе до рефакторингу.

• Дробові обов'язки

  Відповідно до принципу єдиної відповідальності, кожен блок коду повинен слугувати точно одній цілі. З менеджером ви можете штучно розділити цю відповідальність.

  Розглянемо, ResourceManagerщо координує життя та доступ до Resourceекземплярів. У додатку є єдиний, ResourceManagerчерез який він набуває Resourceекземпляри. У цьому випадку немає жодної реальної причини, чому функцію ResourceManagerекземпляра не можна обслуговувати статичними методами у Resourceкласі.

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

  Часто менеджера вводять, щоб абстрагувати основні проблеми з об'єктами, якими він управляє. Ось чому менеджери піддаються зловживанням як стрічкових посібників для погано розроблених систем. Абстракція - це хороший спосіб спростити складну систему, але назва "менеджер" не дає поняття щодо структури абстракції, яку вона представляє. Це справді фабрика, чи проксі, чи щось інше?

Звичайно, менеджери можуть бути використані для більше, ніж просто зла, з тих же причин. Що EventManagerтаке насправді - Dispatcherвикликає події з джерел і пересилає їх до зацікавлених цілей. У цьому випадку має сенс відокремити відповідальність за отримання та відправлення подій, оскільки людина Event- це лише повідомлення без поняття походження та призначення.

Пишу Dispatcherв Eventвипадках по суті тієї ж самої причини ми пишемо GarbageCollectorабо Factory:

Менеджер знає, що його корисна навантаження не повинна знати.

Я вважаю, що це найкраще виправдання для створення класу, подібного до менеджера. Коли у вас є якийсь об'єкт «корисного навантаження», який поводиться як значення, він повинен бути максимально дурним, щоб загальна система залишалася гнучкою. Щоб надати сенсу окремим екземплярам, ​​ви створите менеджера, який змістовно координує ці екземпляри. У будь-якій іншій ситуації менеджерам непотрібно.

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

Простий приклад, щоб проілюструвати мою думку: перед тим, як був названий заводський зразок , люди використовували його, але вони не знали, як це назвати. Так, хтось, хто мав написати фабрику для свого Fooкласу, можливо, назвав це FooAllocationManager. Це не поганий дизайн, це лише брак фантазії.

І тоді комусь потрібно впровадити клас, який підтримує безліч заводів і роздає їх різним предметам, які просять їх; і він називає свій клас FactoryManagerтому, що слово Industryпросто ніколи йому не прийшло в голову, або він думав, що це буде неприховано, тому що він ніколи раніше не чув про щось подібне в програмуванні. Знову випадок браку фантазії.

Наявність безлічі класів "менеджер" часто є симптом анемічної моделі домену , де логіка домену виводиться з доменної моделі і замість цього розміщується в класах менеджерів, які більш-менш прирівнюються до сценаріїв транзакцій . Тут небезпека полягає в тому, що ви в основному повертаєтесь до процедурного програмування - що саме по собі може бути, а може і не бути хорошою справою залежно від вашого проекту - але той факт, що його не розглядали чи не планували, є справжньою проблемою.

Дотримуючись принципу "інформаційного експерта" , логічна операція повинна розташовуватися якомога ближче до даних, які вона вимагає. Це означатиме переміщення логіки домену назад у доменну модель, так що саме ці логічні операції мають помітний вплив на стан доменної моделі, а не «менеджери» змінюють стан доменної моделі зовні.

Коротка відповідь: це залежить .

Існує кілька різних форм "класів менеджерів", деякі з них хороші, інші - погані, і для більшості з них багато що залежить від контексту, якщо введення класу менеджера - це правильна річ. Хорошим початковим пунктом для їх правильності є дотримання принципу єдиної відповідальності - якщо ви точно знаєте, за що відповідає ваш клас керівника (а що ні), у вас буде набагато менше проблем з їх розумінням.

Або безпосередньо відповісти на ваше запитання: це не кількість класів менеджерів, які вказують на погану архітектуру, але занадто багато з них з незрозумілими обов'язками або з надто великими проблемами.

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

Незважаючи на те, що розповсюдженість менеджерів може бути пов’язана з поганим судженням щодо дизайну, вони можуть також вирішувати неякісні дизайнерські рішення або проблеми несумісності з іншими компонентами в складеному дизайном, сторонніми компонентами інтерфейсу або сторонніми веб-сервісами із дивним інтерфейсом як приклади.

Ці приклади демонструють, де вони надзвичайно корисні для певних ситуацій у зменшенні загальної складності та просуванні слабкої зв'язку між різними компонентами та шарами шляхом інкапсуляції «потворного коду» в одному місці. Хоча одна думка полягає в тому, що люди вважають заманливим зробити менеджерів одиночними, я б радив цього, і, звичайно, так, як інші запропонували Принцип єдиної відповідальності завжди слід дотримуватися.

Чи можуть заняття менеджером бути ознакою поганої архітектури?

Ви відповіли на своє запитання: вони не повинні бути ознакою поганого дизайну.

За винятком прикладу у вашому запитанні з EventManager, є ще один приклад: у схемі дизайну MVC презентатор може розглядатися як менеджер для класів моделі / перегляду.

Однак якщо ви неправильно використовуєте поняття, то це ознака поганого дизайну та, можливо, архітектури.

Коли в класі є "Менеджер" в імені, остерігайтеся проблеми класу God (один із занадто великими обов'язками). Якщо важко описати, за який клас відповідає його ім’я, то це знак попередження дизайну.

Погані класи менеджерів убік, найгірше ім’я, яке я коли-небудь бачив, було "DataContainerAdapter"

"Дані" мають бути ще однією із заборонених підрядків у іменах - це всі дані, "дані" не дуже розказують у більшості доменів.

Класи менеджерів - як і майже будь-який клас, що закінчується на "-er" - є злими і не мають нічого спільного з OOP. Тож для мене це ознака поганої архітектури.

Чому? Ім'я "-er" означає, що дизайнер коду здійснив певні дії та перетворив його на клас. В результаті у нас є штучне утворення, яке відображає не якусь відчутну концепцію, а певну дію. Це звучить дуже процедурно.

Крім того, зазвичай такі класи беруть деякі дані і працюють над ними. Це філософія пасивних даних та активних процедур, і вона знайшла своє місце в процедурному програмуванні. Якщо ви це усвідомлюєте, в класах менеджерів немає нічого поганого, але це не OOP.

Об’єктно-мислення означає, що предмети роблять речі самі. Відкрийте для себе свій домен , побудуйте смислові мережі , нехай ваші об’єкти - живі організми, розумні та відповідальні люди.

Такі об'єкти не потрібно контролювати. Вони знають, що робити і як робити. Тож класи менеджерів двічі порушують принципи ООП. Окрім класу "-er", він контролює й інші об'єкти. Але це залежить від менеджера. Це він контролює - він поганий керівник. Якщо він координує - він хороший менеджер. Ось чому лист "С" у MVC повинен бути написаний як "Координатор".

Правильна відповідь на це питання:

1. Це залежить.

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