Классы именования - как избежать вызова всего "Менеджера <WhatEver>"?

Ответ 1

Я задал похожий вопрос, но, где это возможно, я пытаюсь скопировать имена уже в .NET Framework и ищу идеи в Java и Android Framework.

Кажется, что Helper, Manager и Util - это неизбежные существительные, которые вы присоединяете для координации классов, которые не содержат состояний и, как правило, являются процедурными и статическими. Альтернативой является Coordinator.

Вы можете получить особенно пурпурные прозы с именами и пойти на такие вещи, как Minder, Overseer, Supervisor, Administrator и Master, но, как я уже сказал, я предпочитаю держать его как имена фреймворков, к которым вы привыкли.

Некоторые другие общие суффиксы (если это правильный термин), которые вы также найдете в .NET Framework:

• Builder
• Writer
• Reader
• Handler
• Container

Ответ 2

Вы можете взглянуть на source-code-wordle.de, я проанализировал там наиболее часто используемые суффиксы имен классов платформы .NET и некоторых других библиотек.

Топ-20:

• атрибут
• типа
• помощник
• коллекция
• Преобразователь
• обработчиком
• Информация
• поставщик
• исключение
• услуги
• Элемент
• менеджер
• node
• опции
• factory
• Контекст
• элемент
• дизайнер
• база
• редактор

Ответ 3

У меня все хорошие имена, и я часто пишу о важности заботы при выборе имен для вещей. По этой же причине я опасаюсь метафор, когда называет вещи. В исходном вопросе "factory" и "synchronizer" выглядят как хорошие имена для того, что они означают. Однако "пастух" и "няня" не являются, потому что они основаны на метафорах. Класс в вашем коде не может быть буквально няней; вы называете это няней, потому что она заботится о некоторых вещах, очень похожих на настоящую няню, которая заботится о детях или детях. Это нормально в неофициальной речи, но не в порядке (на мой взгляд) для обозначения классов в коде, который должен поддерживаться тем, кто знает, кто знает, когда.

Почему? Потому что метафоры зависят от культуры и часто зависят от личности. Для вас, назвав класс "нянькой", может быть очень ясным, но, возможно, это не так понятно кому-то другому. Мы не должны полагаться на это, если вы не пишете код, который предназначен только для личного использования.

В любом случае соглашение может сделать или сломать метафору. Использование "factory" само по себе основано на метафоре, но в течение довольно долгого времени и в настоящее время довольно хорошо известно в мире программирования, поэтому я бы сказал, что он безопасен в использовании. Однако "няня" и "пастух" неприемлемы.

Ответ 4

Мы могли бы обойтись без классов xxxFactory, xxxManager или xxxRepository, если бы мы правильно смоделировали реальный мир:

Universe.Instance.Galaxies["Milky Way"].SolarSystems["Sol"]
        .Planets["Earth"].Inhabitants.OfType<Human>().WorkingFor["Initech, USA"]
        .OfType<User>().CreateNew("John Doe");

; -)

Ответ 5

Это звучит как скользкий склон к тому, что было бы размещено на thedailywtf.com, "ManagerOfPeopleWhoHaveMortgages" и т.д.

Я полагаю, что один монолитный класс Менеджера не очень хороший дизайн, но использование "Менеджера" неплохое. Вместо UserManager мы можем разбить его на UserAccountManager, UserProfileManager, UserSecurityManager и т.д.

"Менеджер" - хорошее слово, потому что он ясно показывает, что класс не представляет реальную вещь "." AccountsClerk" - как я могу рассказать, является ли класс, который управляет данными пользователя, или представляет кого-то, кто является секретарем учетной записи для своей работы?

Ответ 6

Поскольку вас интересуют статьи в этой области, вам может быть интересна статья Стивена Егге "Выполнение в Королевстве существительных":

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

Ответ 7

Когда я думаю об использовании Manager или Helper в имени класса, я считаю его запахом кода, что означает, что я еще не нашел правильную абстракцию и/или нарушаю принцип единой ответственности, поэтому рефакторинг и привлечение большего внимания к дизайну часто упрощают именование.

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

Классы бизнес-моделей могут быть трудными, потому что они разные для каждого домена. Есть несколько терминов, которые я использую много, например Policy для классов стратегии внутри домена (например, LateRentalPolicy), но они обычно вытекают из попытки создать "вездесущий язык", который вы можете поделиться с бизнес-пользователями, проектировать и именовать классы, чтобы они моделировали реальные идеи, объекты, действия и события в реальном мире.

Классы технической инфраструктуры немного проще, потому что они описывают домены, которые мы знаем очень хорошо. Я предпочитаю включать имена шаблонов дизайна в имена классов, например InsertUserCommand, CustomerRepository, или SapAdapter.. Я понимаю озабоченность по поводу передачи реализации вместо намерения, но шаблоны дизайна выходят за эти два аспекта дизайна классов - по крайней мере, работа с инфраструктурой, где вы хотите, чтобы дизайн реализации был прозрачным, даже когда вы скрываете детали.

Ответ 8

Будучи аутистом с шаблонами, определенными (скажем) GOF book, а имена объектов после этого дают мне длинный путь в классах именования, организовывать их и сообщать о намерениях. Большинство людей поймут эту номенклатуру (или, по крайней мере, большую ее часть).

Ответ 9

Если я не могу придумать более конкретное имя для моего класса, чем XyzManager, мне было бы необходимо пересмотреть, действительно ли это функциональность, которая принадлежит вместе в классе, то есть архитектурный "запах кода".

Ответ 10

Я думаю, что самое важное, о чем нужно помнить, - это достаточно описательное имя? Можете ли вы рассказать, глядя на имя, которое должен выполнять класс? Использование таких слов, как "Менеджер", "Сервис" или "Обработчик" в именах классов, может считаться слишком общим, но поскольку многие программисты используют их, он также помогает понять, для чего предназначен класс.

Я сам много использовал фасад-образ (по крайней мере, я думаю, что он называется). Я мог бы иметь класс User, который описывает только одного пользователя, и класс Users, который отслеживает мою "коллекцию пользователей". Я не называю класс a UserManager, потому что мне не нравятся менеджеры в реальной жизни, и я не хочу напоминать им:) Просто использование формы множественного числа помогает мне понять, что делает класс.

Ответ 11

Специально для С# я обнаружил, что в "Руководстве по проектированию инфраструктуры: условные обозначения , идиомы и шаблоны для многократно используемых библиотек .NET" содержится много полезной информации о логике именования.

Что касается поиска более конкретных слов, я часто использую тезаурус и прыгаю через связанные слова, чтобы найти подходящий. Я стараюсь не тратить на это много времени, хотя по мере развития я придумываю более SuchAndSuchManager имена или иногда осознаю, что SuchAndSuchManager действительно должен быть разбит на несколько классов, и тогда имя этого устаревшего класса становится не вопрос.

Ответ 12

Я считаю, что критическая вещь здесь должна быть последовательной в пределах видимости вашего кода, т.е. пока все, кому нужно смотреть/работать на вашем коде, понимают ваше соглашение об именах, тогда это должно быть хорошо, даже если вы решите называть их "CompanyThingamabob" и "UserDoohickey". Первая остановка, если вы работаете в компании, - это увидеть, существует ли соглашение об организации для именования. Если нет или вы не работаете в компании, тогда создайте свои собственные термины, которые имеют для вас смысл, передайте их нескольким доверенным коллегам/друзьям, которые, по крайней мере, ошибочно кодируют код, и добавят любую обратную связь, которая имеет смысл.

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

Ответ 13

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

Например, UserRecordsClerk может быть лучше объяснен как расширение общего интерфейса RecordsClerk, который реализуется как UserRecordsClerk, так и CompanyRecordsClerk, а затем специализируется на нем, то есть можно посмотреть на методы в интерфейсе, чтобы увидеть, что делают его подклассы в целом.

См. книгу, например Design Patterns для информации, это отличная книга и может помочь вам разобраться, где вы собираетесь быть с вашим кодом - если вы еще не используете его!; o)

Я считаю, что если ваш шаблон хорошо выбран и используется насколько это уместно, тогда достаточно достаточно непроницательных простых имен классов!