Использование пространства имен 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 ключевое слово
• Пространства имен могут иметь псевдонимы, классы являются типами и могут определяться по типам.
• Пространства имен могут быть добавлены;вы можете добавить к нему функциональность в любое время и добавить к нему напрямую
• Классы нельзя добавлять без создания нового производного класса.
• Пространства имен могут иметь предварительные объявления.
• С помощью классов вы можете иметь частных и защищенных членов.
• Классы можно использовать с шаблонами

Как именно разделить:

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

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

Answer 2

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

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

Answer 3

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

Answer 4

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

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

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

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

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

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