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

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

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

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

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

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

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

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

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

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

• Няня - Помогает объектам достигать «пригодного для использования» состояния после создания - например, путем подключения к другим объектам

• и т. д.

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

PS: меня также интересуют ссылки на статьи и блоги, обсуждающие эту проблему. Для начала вот оригинальная статья, которая заставила меня задуматься об этом: именование классов Java без «менеджера»

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

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

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

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

• Какие имена вы регулярно посещаете / добавляете на занятия?
• Каков наилучший подход к именованию классов?
• Книга: Шаблоны проектирования: элементы многоразового объектно-ориентированного программного обеспечения (в твердом переплете)
• Книга: Шаблоны корпоративной архитектуры приложений (в твердом переплете)
• Книга: Образцы реализации (Мягкая обложка)

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

• координатор
• строитель
• писатель
• читатель
• укротитель
• Контейнер
• протокол
• цель
• конвертер
• контроллер
• Посмотреть
• завод
• сущность
• ведро

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

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

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

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

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

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

• Builder
• Writer
• Reader
• Handler
• Container

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

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

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

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

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

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

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

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

;-)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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