Я вытащил отсюда термин «смурф» (номер 21). Чтобы избавить кого-то, кто не знаком с проблемой, именование Smurf - это префикс префикса группы связанных классов, переменных и т. Д. С общим префиксом, так что в итоге вы получаете «a SmurfAccountView
pass a SmurfAccountDTO
to SmurfAccountController
» и т. Д.
Решение, которое я обычно слышал, заключается в создании пространства имен smurf и отбрасывании префиксов smurf. В целом это хорошо мне помогло, но я сталкиваюсь с двумя проблемами.
Я работаю с библиотекой с
Configuration
классом. Его можно было бы назвать,WartmongerConfiguration
но он находится в пространстве имен Wartmonger, поэтому он просто называетсяConfiguration
. У меня также естьConfiguration
класс, который можно вызыватьSmurfConfiguration
, но он находится в пространстве имен Smurf, поэтому он будет избыточным. В моем коде есть места, гдеSmurf.Configuration
появляется рядом,Wartmonger.Configuration
и ввод полностью определенных имен неуклюж и делает код менее читабельным. Было бы лучше иметь дело с aSmurfConfiguration
и (если бы это был мой код, а не библиотека)WartmongerConfiguration
.В
Service
моем пространстве имен Smurf есть класс, который можно было бы вызватьSmurfService
.Service
это фасад на вершине сложной библиотеки Smurf, которая выполняет задания Smurf.SmurfService
кажется лучшим именем, потому чтоService
без префикса Smurf это невероятно универсально. Я могу признать, что этоSmurfService
было уже общее, бесполезное имя, и удаление смарфа просто сделало это более очевидным. Но его можно было бы назватьRunner
иLauncher
т. Д., И мне все равно было бы «легче»,SmurfLauncher
потому что я не знаю, что онLauncher
делает, но я знаю, что онSmurfLauncher
делает. Вы можете утверждать, что то, чтоSmurf.Launcher
делает, должно быть столь же очевидно, какSmurf.SmurfLauncher
, но я мог видеть, что Smurf.Launcher - это некий класс, связанный с настройкой, а не класс, запускающий smurfs.
Если есть открытый и закрытый способ справиться с любым из них, это было бы здорово. Если нет, каковы некоторые распространенные практики, чтобы смягчить их раздражение?
источник
Smurf.Launcher
запуск Smurfs, или это запуститьSmurfJob
S? Возможно, это можно назватьSmurf.JobLauncher
?SmurfJob
s или технически запускает их в соответствии с языком документации Smurf. В свете этого и других ответов я собираюсь переименоватьSmurfService
вSmurfJobRunner
. Кажется, номер 1 не имеет лучшего разрешения, как я ожидал. Я могу видеть случаи, когда подходSmurfConfiguration
был бы правильным решением, но в моем случае я думаю, чтоConfiguration
это лучше, даже несмотря на трудностиWartmonger.Configuration
.Smurf.Configuration
иSmurfConfiguration
чувствуешь себя иначе? Конечно, это не дополнительный символ, не так ли? (Сократите до,Config
если проблема в длине.) Есть лиSmurf.Configuration
проблемы, которыхSmurfConfiguration
нет?Ответы:
Вы поднимаете некоторые хорошие моменты.
Что касается дублирующих классов, вы можете использовать псевдонимы классов в C #. Используйте, например,
using ColorScheme = The.Fully.Qualified.Namespace.Outlook2007ColorScheme;
см. Этот пост на StackOverflow . Вы не указали свой язык программирования, но я понял из того, что вы написали. Итак , где вы имеете дело с двумя разными проектами, вы можете алиас ихSmurfConfiguration
иWartmongerConfiguration
что позволило бы неоднозначность при употреблении обоих классов.Поскольку служба подвержена влиянию внешних приложений, я не вижу проблем в маркировке службы именем вашего приложения, поэтому в этом случае
SmurfService
она будет действительной, так как она фактически устраняет неоднозначность групп служб в приложении-потребителе.Я чувствую, что пространства имен следует использовать, чтобы избежать такого стиля именования. Это усложняет получение кода и проверку по номиналу, что такое класс, не читая MyCompanyMyProductMyAreaClassName. Использование метода псевдонимов позволяет уменьшить неоднозначность, где это необходимо. Я думаю, что единственное время, когда вы должны вносить сложность в свое наименование, это, как я указывал в # 2, когда люди будут потреблять услугу. Именно здесь имеет смысл использовать этот стиль именования, потому что, если у потребителя есть множество услуг, он потребляет неоднозначность.
источник
org.apache.smurfville.wartmonger.configuration
. Это, к сожалению, исключает псевдонимы. 2 - это сплошная точка, поэтому я собираюсь сохранить Smurf для брендинга Сервиса.Смысл пространств имен в том, что вы можете иметь классы с одинаковыми именами из разных библиотек без их коллизии. Когда вам нужно использовать один и тот же именованный класс из обоих, вам нужно убрать неоднозначность, добавив один или оба префикса к области его пространства имен.
Тем не менее, неплохо иметь кучу классов Smurf, если Smurf расскажет вам что-то конкретное о классе. Имена классов должны быть достаточно наглядными, чтобы дать вам некоторую информацию о том, что делает класс.
Точно так же
DBSession
может взятьDBRequest
объект, который возвращаетDBResponse
объект.HttpSession
Также может работать наHttpRequest
иHttpResponse
объекты.Это классы Smurf с целью.
Они могут жить в
MyCompany
пространстве имен , ноMyCompanyHttpSession
иMyCompanyDBSession
не дает вам никакой больше информации , чем было раньше. В этом случае бросьте Smurf и сделайте его пространством имен.источник
Я сталкивался с той же самой путаницей и раньше, и обычно это действительно вопрос о том, включать ли мы это как часть своего названия.
Вы упоминаете
SmurfConfiguration
и вWartmongerConfiguration
качестве потенциальных видов конфигураций. Вы указываете, что вы удалили прилагательное (его вид) в его пространство имен, так что осталось только ванильConfiguration
. Я бы избегал этого.Это все равно, что решить, что клубничное мороженое - это просто мороженое в пространстве имен клубники и аналогично с шоколадом, но то, что произошло, вы отдалили прилагательное, которое придает ему идентичность с самой вещью. Это не мороженое в категории клубники. Это клубничное мороженое - своего рода мороженое.
Давайте представим, что в вашем приложении вы импортируете
Strawberry.IceCream
класс, а затем начинаете создание экземпляра непосредственно изIceCream
.Это может показаться неплохим, до того момента, пока вы не импортируете другой
IceCream
класс. Теперь вы вернулись к первоначальной проблеме необходимости как-то различать их, что проблематично. Все, что вы хотели, было:Пространства имен лучше оставить, чтобы избежать потенциальных конфликтов между третьими сторонами, которые могут случайно представлять те же понятия в своих библиотеках. Однако, когда один разработчик создает библиотеку или проект, он должен назвать каждое понятие уникальным и использовать пространства имен в качестве папок только для организации. Часто имя папки можно найти в названии концепций, которые она организует, и это нормально.
источник
Это определенно хорошее практическое правило: если у вас есть общий префикс для нескольких классов, то они, вероятно, заслуживают того, чтобы перейти в свое собственное пространство имен. Чтобы решить проблему, тогда, когда вам нужно использовать классы с одинаковыми именами из двух пространств имен:
1) Псевдоним пространства имен, хотя я бы сделал его кратким и, в сущности, любое естественное сокращение, может быть, даже просто 1 букву:
Затем всегда ставьте префикс, где бы он ни использовался, и присваивайте экземпляры соответствующим образом:
2) Псевдоним класса, как предлагается в другом ответе.
3) Любую библиотеку, которой вы управляете, не используйте термин «Конфигурация». Используйте тезаурус: например, «Настройки», «Модель», «Параметры». В любом случае, это может быть более значимым для контекста: например, если бы Smurf был своего рода модулем численного анализа, вы бы написали, что «Параметры» были бы лучше для его конфигурации. Используйте конкретный словарь, связанный с контекстом модуля, в ваших интересах, чтобы придумать уникальные имена, которые обладают уникальностью, даже когда они смешаны с другими пространствами имен. Я чувствую, что это может быть своего рода ответом на OP-вопрос 2.
4) Рефакторинг кода, чтобы вам не приходилось смешивать использование конфигурации из двух разных мест. Детали этого до вас.
5) Объедините две конфигурации в одну, прежде чем передать ее в свой класс. Используйте комбинированный класс conf для представления:
Короткие имена переменных-членов теперь как бы достигают того же, что и псевдоним класса / пространства имен.
источник
Кажется странным, что добавление одной точки к названию беспокоит вас.
Если обе конфигурации
Smurf
иWartmonger
конфигурации используются вместе в одном месте, но по отдельности они используются в нескольких местах - тогда пространство имен, безусловно, является хорошим подходом.Имея пространство имен даст возможность использовать «чистые» имена во внутреннем коде, где с префиксами вы в конечном итоге с помощью
SmurfConfiguration
внутриSmurfService
«s внутренний код, который может стать раздражает каждый раз, когда вы откроете этот код.источник