Коли клей чи клас управління занадто багато роблять?

Я схильний будувати централізовані класи, які керують іншими класами в моїх проектах. Він не зберігає все сам, але більшість запитів даних спочатку перейде до "менеджера". Дивлячись на відповідь на це запитання, я помітив термін "Об'єкт Бога". У Вікіпедії зрозуміло, що це антипатрійт.

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

design design-patterns anti-patterns

— jprete
джерело

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

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

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

Якщо його називають "Менеджер", "Помічник" або "Сервіс", швидше за все, він занадто великий. Як тільки ви дійсно розберете, якою має бути відповідальність класу, вам буде легше делегувати інші обов'язки.
Якщо це називається "Контролер", він повинен відповідати за контроль взаємодії між купою інших класів ... і більше нічого.
Якщо він передає дані та повідомлення між різними фізичними вузлами, то або він повинен мати справу з перетворенням конкретного повідомлення в серіалізовану форму, або він обробляє механізм передачі. Наприклад, у вас може бути один клас, який перетворює банківську транзакцію в XML, і інший клас, який надсилає цей XML через HTTP.
Якщо він передає події між різними модулями в додатку, то він повинен відповідати за повідомлення слухачам про те, коли подію порушено, і більше нічого.

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

— Лужник
джерело

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

— jprete