it-roy-ru.com

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

Давным-давно я прочитал статью (я полагаю, запись в блоге), которая поставила меня на "правильный путь" в отношении именования объектов: будьте очень скрупулезны в отношении именования объектов в вашей программе.

Например, если бы мое приложение (как типичное бизнес-приложение) обрабатывало пользователей, компании и адреса, у меня были бы User, Company и Address доменный класс - и, возможно, где-то UserManager, CompanyManager и AddressManager всплыли бы, что обрабатывает эти вещи.

Так что вы можете сказать, что делают эти UserManager, CompanyManager и AddressManager? Нет, потому что Менеджер - это очень очень общий термин, который подходит для всего, что вы можете делать с объектами вашего домена.

В статье, которую я прочитал, рекомендуется использовать очень конкретные имена. Если бы это было приложение C++, а заданием UserManager было выделение и освобождение пользователей из кучи, оно не управляло бы пользователями, а охраняло их рождение и смерть. Хм, может быть, мы могли бы назвать это UserShepherd.

Или, возможно, задача UserManager состоит в проверке данных каждого объекта User и криптографической подписи данных. Тогда у нас будет UserRecordsClerk.

Теперь, когда эта идея застряла у меня, я пытаюсь применить ее. И найти эту простую идею удивительно сложно.

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

В конечном счете, я хотел бы иметь что-то вроде каталога шаблонов (часто шаблоны проектирования легко предоставляют имена объектов, например, фабрика )

  • Factory - создает другие объекты (наименования взяты из шаблона проектирования)
  • Пастух - Пастух управляет временем жизни объектов, их созданием и отключением.
  • Синхронизатор - копирует данные между двумя или более объектами (или иерархиями объектов)
  • Няня - Помогает объектам достигать "пригодного для использования" состояния после создания - например, путем подключения к другим объектам

  • и т. д.

Итак, как вы решаете эту проблему? У вас есть постоянный словарный запас, вы придумываете новые имена на лету или считаете, что называть вещи не так важно или неправильно?

П.С .: Меня также интересуют ссылки на статьи и блоги, в которых обсуждается проблема. Для начала вот оригинальная статья, которая заставила меня задуматься об этом: Naming Java Классы без 'Manager'


Обновление: резюме ответов

Вот небольшое резюме того, что я узнал из этого вопроса в то же время.

  • Старайтесь не создавать новые метафоры (няня)
  • Посмотрите, что делают другие фреймворки

Другие статьи/книги на эту тему:

И текущий список префиксов/суффиксов имен, которые я собрал (субъективно!) Из ответов:

  • Координатор
  • Строитель
  • Писатель
  • Читатель
  • Укротитель
  • Контейнер
  • Протокол
  • Цель
  • Конвертер
  • Контроллер
  • Посмотреть
  • Завод
  • Сущность
  • Ведро

И хороший совет для дороги:

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

1084
froh42

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

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

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

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

  • Builder
  • Writer
  • Reader
  • Handler
  • Container
181
Chris S

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

Лучшие 20 являются:

  • атрибут
  • тип
  • помощник
  • коллекция
  • конвертер
  • обработчик
  • информация
  • поставщик
  • исключение
  • оказание услуг
  • элемент
  • менеджер
  • узел
  • вариант
  • завод
  • контекст
  • вещь
  • дизайнер
  • база
  • редактор
108
Markus Meyer

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

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

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

61
CesarGon

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

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

;-)

46
herzmeister

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

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

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

35
Mr. Boy

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

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

23
stusmith

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

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

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

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

19
Jeff Sternal

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

10
Jasper van den Bosch

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

9
Brian Agnew

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

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

7
Droozle

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

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

5
AaronLS

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

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

2
Lazarus

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

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

Обратитесь к такой книге, как Шаблоны проектирования , это отличная книга, и она может помочь вам разобраться в том, где вы собираетесь быть со своим кодом - если вы его еще не используете! ; О)

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

2
Caroline