Именование классов - как не называть все «менеджером» ‹WhatEver›?

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

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

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

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

• 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» - как я должен определить, является ли это классом, который управляет пользовательскими данными, или представляет кого-то, кто является клерком по работе с учетными записями?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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