Что лучше, чем менеджер, процессор и т.д.?

Ответ 1

Ждите!

Пункт книги состоит в том, что Менеджер в имени класса означает, что класс выполняет несколько операций. Роберт К. Мартин в этом разделе ссылается на принцип единой ответственности!

Это не о имени, а о классах, которые обычно называются так. Изменение имени не уменьшит обязанности класса!

Ответ 2

Моя догадка заключается в том, что книга делает это потому, что она пытается побудить вас выбрать более описательное имя для вашего класса. Здесь нет "соглашения об именах"; что проблема, в которую вы попали, в первую очередь. Любое универсальное соглашение об именах не сможет рассмотреть конкретный класс и выбрать наилучшее имя для него. Выразительность важнее, чем соблюдение соглашения об именах. Вызов класса "Менеджер" или "Процессор" не говорит об этом очень сильно и что он делает с человеком, который читает ваш код в первый раз.

Если вы действительно не можете придумать ничего лучшего, нет ничего неправильного в названии класса ConnectionManager. Но я бы назвал его по типу коллекций, которыми он управляет. Или, может быть, он управляет этими коллекциями. Или почему он управляет этими коллекциями.

Также подумайте, что следующие правила "один размер-подходит для всех" редко помогали кому-либо писать лучший код (по крайней мере, не лучше в смысле "более понятный" или "более выразительный" ). Я предпочитаю постфиксные имена из всех моих родных классов-оболочек с Manager. Например, у меня могут быть классы с именем DwmManager или VisualStylesManager. В этом очень конкретном случае это что-то значит для меня. Если я вижу класс с именем Manager в моей базе кода, я знаю, что он обертывает кучу тесно связанных функций. Вы должны принять решение в каждом конкретном случае, понимая, что в конечном итоге вы пытаетесь выполнить.

Если вы прочитали Code Complete и пропустили часть написания кода, который был бы понятным и понятным (и, следовательно, поддерживаемым), возможно, вы пропустили эту точку.

Ответ 3

В примере вашего класса ConnectionManager возможно, что класс более указывает на дефект дизайна, который требует "плохого" имени. Класс делает что-то помимо выполнения действий, которые так же легко выполняются в одноэлементном подклассе MyDatabaseConnection?

Ответ 4

Возьмем, к примеру, имя DataProcessor.

Во-первых, верно, что каждая функция работает с данными, принимает данные или возвращает некоторые данные, если только

void f(void)

Но если это такой тип функции, то он, безусловно, что-то делает, поэтому в любом случае это процессор.

DataProcessor - это вообще что-то, потому что он не говорит, что он манипулирует и как. Таким образом, вы должны заменить

DataProcessor с UserInfoStore, например.

Ответ 5

Я часто использую слово "Initialize" или "Initializer". Если это что-то еще, я обычно думаю о синониме, который действительно длинный по сравнению с первым, о котором я думал. Я также использую термин "Parser" и другие вещи.

Ответ 6

OH, NO!!

Пожалуйста, не пугайтесь общих заявлений о том, как вы должны "называть" вещи. В конце концов, они ваши вещи. Возможно, ваше имя "Менеджер" лучше, чем "Менеджер соединений", потому что оно короче. Тем более, если этот раздел вашего кода в основном управляет "соединениями" и еще немного.

Я считаю, что такие книги имеют очень полезные идеи, но только для кодеров, которые никогда не прочтут их. Зачем? Потому что инженеры, которые делают, читают такие книги, уже усвоили и включили в них самые надежные принципы. И кодеры, которые не будут читать их, не заботятся.

Ответ 7

"Помощник", "Обычный", "Ядро", "Утилиты" кажутся равными или худшими, чем "Менеджер". Они ничего не говорят о том, что они делают.
"Factory" здесь абсолютно неверен. Альтернативными именами являются "Координатор" или "Контроллер".

yous said: У меня есть класс, который отвечает за запуск и остановку соединений. Поэтому я назвал его ConnectionManager.

Если класс просто "запустит" и "остановит" соединение, почему бы не "ConnectionSwitcher"?

ты сказал: я использовал их везде.

У меня тоже много классов менеджера. Сегодня я решил изменить имя "Account Manager". Он использует репозиторий учетной записи для выполнения операций CRUD.

Я разделил его на "Аккаунт Безопасность" и "Аккаунт Операции".

Они существуют в пространстве имен MyProject.BusinessLogic, и оба используют класс AccountRepository, который раскрывает методы CRUD. Первый отвечает за такие действия, как "Вход" и "ChangePassword". Последний отвечает за операции CRUD против базы данных, но регулируется какой-то логикой, например, если существует какая-либо запись в реестре для учетной записи, ее нельзя удалить. ( "AccountOperations" использует также другие репозитории для получения необходимой информации)

Я не доволен "операциями", и я ищу что-то лучше (координатор, супервизор...), но это начало.

Мое дело было бы примером того, как думать об этом.

Ответ 8

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