Использование именования пространства имен С++ и правила именования

В проекте мы пытаемся достичь соглашения об использовании пространства имен. Мы решили, что первый уровень будет "productName", а второй - "moduleName".

productName::moduleName

Теперь, если модуль является своего рода программным модулем, нет необходимости добавлять третье пространство имен. Например, чтобы добавить "str": productName:: utilityModuleName:: str - разделить пространство, в котором все связанные с "строками" вещи будут идти.

Если модуль является основным бизнес-модулем, у нас есть много возможностей и почти нет согласия.

Например

class productName::mainModuleName::DomainObject

и

class productName::mainModuleName::DomainObjectSomethingElseViewForExample

может быть как в

namespace productName::mainModuleName::domainObject
class Data
class ViewForExample

Почему мы должны создавать внутренние, а не частные классы, а не пространства имен? Почему мы должны создавать класс, где все методы являются статическими (за исключением случаев, когда этот класс будет параметром шаблона)?

Проект состоит из 1Gb исходного кода. Итак, что лучше всего разделить модули на пространства имен в С++?

Ответ 1

Какие пространства имен предназначены для:

Пространства имен предназначены для установки контекста только для того, чтобы у вас не было именных конфиг.

Общие правила:

Указание слишком большого контекста не требуется и приведет к большему количеству неудобств, чем это стоит.

Итак, вы хотите использовать свое лучшее суждение, но все равно следуйте этим двум правилам:

Не используйте слишком много общего при использовании пространств имен
Не слишком конкретны при использовании пространств имен

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

Почему пространства имен, которые являются слишком общими, не помогают:

Проблема с разделением пространства имен, начинающимся с имени продукта, заключается в том, что у вас часто будет компонент кода или какая-то базовая библиотека, общая для нескольких продуктов.

Вы также не будете использовать пространства имен Product2 внутри Product1, поэтому явно указывать его бессмысленно. Если вы включили файлы Product2 в Product1, то это преобразование имен еще полезно?

Почему слишком пространственные пространства имен не являются полезными:

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

Классы со всеми статическими шаблонами:

"Почему мы должны создавать внутренние, а не частные классы, а не пространства имен? Почему мы должны создавать классы, где все методы являются статическими"

Некоторые отличия:

Пространства имен могут подразумеваться с помощью ключевого слова using
Пространства имен могут быть сглажены, классы являются типами и могут быть typedef'ed
Пространства имен могут быть добавлены; вы можете добавить функциональность к нему в любое время и добавить к нему напрямую.
Классы не могут быть добавлены без создания нового производного класса
Пространства имен могут иметь форвардные объявления
С помощью классов вы можете иметь закрытых членов и защищенных членов.
Классы могут использоваться с шаблонами

Точно как разделить:

"Проект состоит из 1 Гб источника код. Итак, какова наилучшая практика для разделить модули на пространства имен в С++?"

Слишком субъективно сказать, как разделить код без точного исходного кода. Разделение на основе модулей, хотя звучит логично, просто не весь продукт.

Ответ 2

Мне кажется, что вы пытаетесь использовать пространства имен в качестве инструмента проектирования. Они не предназначены для этого, они предназначены для предотвращения столкновений имен. Если у вас нет столкновений, вам не нужны пространства имен.

Ответ 3

Это все субъективно, но я бы смутился, чтобы пройти более трех уровней. В какой-то момент это становится слишком громоздким. Поэтому, если ваша база кода очень, очень большая, я бы сохранил ее довольно мелкой.

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

Ответ 4

Я разделяю пространства имен в зависимости от его использования:

У меня есть отдельное пространство имен, где я определил все мои интерфейсы (чистые виртуальные классы).

У меня есть отдельное пространство имен, где я определил свои классы библиотек (например, библиотека db, библиотека обработки).

И у меня есть отдельное пространство имен, где у меня есть мои основные бизнес-объекты (бизнес-логика) (например, purchase_order и т.д.).

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

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