Хорошие соглашения об именах пространств имен

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

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

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

  • BusinessObjects.Обслуживание.Контакты
  • BusinessObjects.Обслуживание.Продукты
  • BusinessObjects.Обслуживание.Классификации
  • .
  • BusinessObjects.Incidents.Contacts
  • BusinessObjects.Incidents.Products
  • BusinessObjects.Incidents.Classifications
  • .
  • BusinessObjects.Search.Contacts
  • BusinessObjects.Search.Products
  • BusinessObjects.Search.Classifications
  • .
  • Даль.Техническое обслуживание.Контакты
  • Даль.Техническое обслуживание.Продукты
  • Dal. Техобслуживание. Классификации
  • .
  • Даль.Инциденты.Контакты
  • Dal.Incidents.Products
  • Дал. Происшествия. Классификации
  • .
  • Даль.Поиск.Контакты
  • Даль.Поиск.Продукты

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

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

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

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

Ответов (7)

Решение

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

"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

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

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

то есть:

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

вместо:

Org.MyCompany.Contacts

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

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

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

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

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

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

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

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

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

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

class Vehicle 

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

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

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

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

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

Также ознакомьтесь с этой статьей MSDN, чтобы узнать о правилах именования пространств имен.

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