Именование классов-Как избежать называть все "менеджером"? [закрытый]

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

топ-20 являются:

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

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

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

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

мы могли бы обойтись без любого 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"и др.

Я полагаю, что правильно, что один монолитный класс менеджера не является хорошим дизайном, но использование "менеджера" не плохо. Вместо 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. Я понимаю озабоченность по поводу передачи реализации вместо намерения, но шаблоны проектирования сочетают эти два аспекта дизайна класса - по крайней мере, когда вы имеете дело с инфраструктурой, где вы хотите реализацию конструкция чтобы быть прозрачным, даже когда вы скрываете детали.

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

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

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

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

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

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

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

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

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

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

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