Я читаю книгу "Чистый код" http://www.amazon.com/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
Автор упоминает, что вы должны избегать таких слов, как Manager, Processor, Data или Info в названии класса. Я использовал это везде. Какие имена лучше? У меня есть класс, который отвечает за запуск и остановку соединений. Поэтому я назвал это ConnectionManager.
Ждите!
Пункт книги состоит в том, что Менеджер в имени класса означает, что класс выполняет несколько операций. Роберт К. Мартин в этом разделе ссылается на принцип единой ответственности!
Это не о имени, а о классах, которые обычно называются так. Изменение имени не уменьшит обязанности класса!
Моя догадка заключается в том, что книга делает это потому, что она пытается побудить вас выбрать более описательное имя для вашего класса. Здесь нет "соглашения об именах"; что проблема, в которую вы попали, в первую очередь. Любое универсальное соглашение об именах не сможет рассмотреть конкретный класс и выбрать наилучшее имя для него. Выразительность важнее, чем соблюдение соглашения об именах. Вызов класса "Менеджер" или "Процессор" не говорит об этом очень сильно и что он делает с человеком, который читает ваш код в первый раз.
Если вы действительно не можете придумать ничего лучшего, нет ничего неправильного в названии класса ConnectionManager. Но я бы назвал его по типу коллекций, которыми он управляет. Или, может быть, он управляет этими коллекциями. Или почему он управляет этими коллекциями.
Также подумайте, что следующие правила "один размер-подходит для всех" редко помогали кому-либо писать лучший код (по крайней мере, не лучше в смысле "более понятный" или "более выразительный" ). Я предпочитаю постфиксные имена из всех моих родных классов-оболочек с Manager. Например, у меня могут быть классы с именем DwmManager или VisualStylesManager. В этом очень конкретном случае это что-то значит для меня. Если я вижу класс с именем Manager в моей базе кода, я знаю, что он обертывает кучу тесно связанных функций. Вы должны принять решение в каждом конкретном случае, понимая, что в конечном итоге вы пытаетесь выполнить.
Если вы прочитали Code Complete и пропустили часть написания кода, который был бы понятным и понятным (и, следовательно, поддерживаемым), возможно, вы пропустили эту точку.
В примере вашего класса ConnectionManager возможно, что класс более указывает на дефект дизайна, который требует "плохого" имени. Класс делает что-то помимо выполнения действий, которые так же легко выполняются в одноэлементном подклассе MyDatabaseConnection?
Возьмем, к примеру, имя DataProcessor.
Во-первых, верно, что каждая функция работает с данными, принимает данные или возвращает некоторые данные, если только
void f(void)
Но если это такой тип функции, то он, безусловно, что-то делает, поэтому в любом случае это процессор.
DataProcessor - это вообще что-то, потому что он не говорит, что он манипулирует и как. Таким образом, вы должны заменить
DataProcessor с UserInfoStore, например.
Я часто использую слово "Initialize" или "Initializer". Если это что-то еще, я обычно думаю о синониме, который действительно длинный по сравнению с первым, о котором я думал. Я также использую термин "Parser" и другие вещи.
OH, NO!!
Пожалуйста, не пугайтесь общих заявлений о том, как вы должны "называть" вещи. В конце концов, они ваши вещи. Возможно, ваше имя "Менеджер" лучше, чем "Менеджер соединений", потому что оно короче. Тем более, если этот раздел вашего кода в основном управляет "соединениями" и еще немного.
Я считаю, что такие книги имеют очень полезные идеи, но только для кодеров, которые никогда не прочтут их. Зачем? Потому что инженеры, которые делают, читают такие книги, уже усвоили и включили в них самые надежные принципы. И кодеры, которые не будут читать их, не заботятся.
"Помощник", "Обычный", "Ядро", "Утилиты" кажутся равными или худшими, чем "Менеджер".
Они ничего не говорят о том, что они делают.
"Factory" здесь абсолютно неверен.
Альтернативными именами являются "Координатор" или "Контроллер".
yous said: У меня есть класс, который отвечает за запуск и остановку соединений. Поэтому я назвал его ConnectionManager.
Если класс просто "запустит" и "остановит" соединение, почему бы не "ConnectionSwitcher"?
ты сказал: я использовал их везде.
У меня тоже много классов менеджера. Сегодня я решил изменить имя "Account Manager". Он использует репозиторий учетной записи для выполнения операций CRUD.
Я разделил его на "Аккаунт Безопасность" и "Аккаунт Операции".
Они существуют в пространстве имен MyProject.BusinessLogic, и оба используют класс AccountRepository, который раскрывает методы CRUD. Первый отвечает за такие действия, как "Вход" и "ChangePassword". Последний отвечает за операции CRUD против базы данных, но регулируется какой-то логикой, например, если существует какая-либо запись в реестре для учетной записи, ее нельзя удалить. ( "AccountOperations" использует также другие репозитории для получения необходимой информации)
Я не доволен "операциями", и я ищу что-то лучше (координатор, супервизор...), но это начало.
Мое дело было бы примером того, как думать об этом.
Не слишком беспокоитесь о названии, не обращайте на него особого внимания, если вам или кому-то действительно не нравится.