Поради щодо того, як зменшити використання класів «менеджер»?

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

Чи слід справді уникати якомога більше занять з менеджерів? Крім того, які статті / статті я повинен прочитати про те, як здійснити альтернативну роботу для загальних / звичайних випадків, коли цих керівників можна усунути?

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

Інша причина запаху коду полягає в тому, що це може означати, що об’єкти вашого домену насправді не дуже добре співвідносяться один з одним. Наприклад, якщо у вас є клас облікового запису, який насправді нічого не знає про клас транзакцій, за винятком того, що він називається Transaction, і їх може бути більше, ніж один, тоді ви знову не маєте дуже яскравої реалізації бізнес-домену. Наприклад, SavingsAccount, можливо, повинен знати, що він не може прийняти DebitTransaction, якщо accountStatus закритий. Дуже багато реалізацій залишать це менеджеру.

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

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

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

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