Классы именования - Как избежать того, чтобы все называть & ltquo; < WhatEver > Manager & rdquo ;? [закрыто]

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

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

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

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

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

Being au fait with patterns as defined by (say) the GOF book, and naming objects after these gets me a long way in naming classes, organising them and communicating intent. Most people will understand this nomenclature (or at least a major part of it).

It sounds like a slippery slope to something that'd be posted on thedailywtf.com, "ManagerOfPeopleWhoHaveMortgages", etc.

I suppose it's right that one monolithic Manager class is not good design, but using 'Manager' is not bad. Instead of UserManager we might break it down to UserAccountManager, UserProfileManager, UserSecurityManager, etc.

'Manager' is a good word because it clearly shows a class is not representing a real-world 'thing'. 'AccountsClerk' - how am I supposed to tell if that's a class which manages user data, or represents someone who is an Accounts Clerk for their job?

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

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

I think the most important thing to keep in mind is: is the name descriptive enough? Can you tell by looking at the name what the Class is supposed to do? Using words like "Manager", "Service" or "Handler" in your class names can be considered too generic, but since a lot of programmers use them it also helps understanding what the class is for.

I myself have been using the facade-pattern a lot (at least, I think that's what it is called). I could have a User class that describes just one user, and a Users class that keeps track of my "collection of users". I don't call the class a UserManager because I don't like managers in real-life and I don't want to be reminded of them :) Simply using the plural form helps me understand what the class does.

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

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

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

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

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

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

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

От Для цикла

В некоторых языках (не C или C++) переменная цикла неизменяема в пределах объем корпуса петли, с любым попытается изменить его значение быть рассматривается как семантическая ошибка. Такой модификации иногда являются результат ошибки программиста, что может быть очень трудно идентифицировать один раз сделанный. Однако только открыто изменения, вероятно, будут обнаружены компилятора. Ситуации, когда передается адрес переменной цикла в качестве аргумента для подпрограммы сделать его очень трудно проверить, потому что поведение рутины в целом неизвестен компилятору.

Так что это, кажется, поможет вам не сжечь руку позже.

Почему бы просто не выбрать , где войти в систему, как 'superman%' , и выполнить итерацию над результирующим набором в вашем коде?

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

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

; -)

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

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

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

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