Соглашения о присвоении имен пространствам имен - PullRequest
3 голосов
/ 25 февраля 2009

Я создаю библиотеку классов для бизнес-приложения CRUD. Основные «категории» бизнес-объектов (со связанными объектами слоя доступа к данным):

  • Техническое обслуживание (для работы с мастером таблицы (основные списки) в базе данных
  • Инциденты (большинство объектов относятся к реальному инциденту)
  • Поиск (очевидный)

На данный момент мои пространства имен настроены следующим образом:

  • BusinessObjects.Maintenance.Contacts
  • BusinessObjects.Maintenance.Products
  • BusinessObjects.Maintenance.Classifications
  • .
  • BusinessObjects.Incidents.Contacts
  • BusinessObjects.Incidents.Products
  • BusinessObjects.Incidents.Classifications
  • .
  • BusinessObjects.Search.Contacts
  • BusinessObjects.Search.Products
  • BusinessObjects.Search.Classifications
  • .
  • Dal.Maintenance.Contacts
  • Dal.Maintenance.Products
  • Dal.Maintenance.Classifications
  • .
  • Dal.Incidents.Contacts
  • Dal.Incidents.Products
  • .
  • Dal.Search.Contacts
  • Dal.Search.Products

Обратите внимание, что каждый класс заканчивается тем же именем.

Это хорошая форма?

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

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

Ответы [ 7 ]

5 голосов
/ 26 февраля 2009

Как правило, хорошей идеей является не называть ваши пакеты после какого-либо конкретного реализованного шаблона, а скорее бизнес или функциональный домен, к которому они относятся.

е:

Org.MyCompany.BusinessObjects.Maintenance.Contacts
Org.MyCompany.BusinessObjects.Incidents.Contacts
Org.MyCompany.BusinessObjects.Search.Contacts

вместо

Org.MyCompany.Contacts

, который будет содержать классы / интерфейсы / объекты / все, что выполняет операции над "Контактами".

5 голосов
/ 26 февраля 2009

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

"Lets take a look at the BusObjConfIntContYYYYmmdd package now..."

Одна проблема, с которой вы можете столкнуться - это имена с небольшими различиями. Из-за того, что длина имен может быть проблемой, ваши глаза могут замаскировать все это и взять только его часть. Был ли когда-нибудь случай, когда это произошло?:

BusinessObjects.Incidents.Classifications
BusinessObjects.Classifications.Incidents

или

BusinessObjects.Forms.ProjectManager.Exportable.Windows.XP
BusinessObjects.Forms.ProductManager.Exportable.Windows.XP

Этот надуманный пример может стать проблемой.

2 голосов
/ 25 февраля 2009

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

Надеюсь, это поможет. В конце концов, это действительно зависит от предпочтений вашей команды ...

1 голос
/ 07 января 2011

Также ознакомьтесь с этой статьей MSDN, в которой приведены рекомендации по именованию пространств имен

.

Имена пространств имен: http://msdn.microsoft.com/en-us/library/ms229026.aspx

1 голос
/ 26 февраля 2009

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

Представьте иерархию классов следующим образом:

class Vehicle 

class Car : Vehicle
class CarRed : Car 
class CarBlue : Car 

class Truck : Vehicle 
class TruckRed : Truck 
class TruckBlue : Truck

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

Эта проблема описана в книге шаблонов проектирования GOF - в частности, в паттерне Bridge.

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

1 голос
/ 26 февраля 2009

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

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

0 голосов
/ 26 февраля 2009

Я использую одно пространство имен на библиотеку и одно на набор исполняемого исходного кода. Имена всегда короткие. Например, в исполняемом файле, над которым я сейчас работаю, у меня есть:

  • ALib - моя общая служебная библиотека
  • Mongo - библиотека моего мини веб-сервера
  • DBLite - моя оболочка SQLite3 и простая персистентный слой
  • Track1 - исполняемый файл (на самом деле пара исполняемых файлов)

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

...