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

Question

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

productName::moduleName

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

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

Например

class productName::mainModuleName::DomainObject

и

class productName::mainModuleName::DomainObjectSomethingElseViewForExample

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

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

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

Проект состоит из 1 ГБ исходного кода. Итак, какова лучшая практика для разделения модулей на пространства имен в C ++?

Answer 1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

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

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

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