Как организовать несколько типов данных в проекте C ++

Question

В нашем проекте (C ++ 14) мы разделили наше программное обеспечение на несколько компонентов по функциональной схеме системы. Каждый из модулей находится в своем собственном пространстве имен, встроенном в общее пространство имен для системы. Мы используем CMake в качестве нашей системы сборки, и каждый компонент представляет собой библиотеку stati c, которая может быть собрана отдельно и в конце связана вместе.

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

Но. Когда мне теперь нужно получить доступ к одной из этих структур данных из других компонентов, я должен включить заголовок из указанного компонента c и иметь зависимость между этими двумя компонентами. И поскольку это общий подход, у нас есть много зависимостей между нашими программными компонентами, что легко приводит к циклическим c зависимостям. : (

В мире C я бы создал GlobalDataStructures.h и добавил бы все структуры данных, которые используются в программной системе.

Что такое (современный) подход C ++ к этому? Каковы лучшие практики?

Answer 1

Идея подхода «C style» в основном разумна.

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

В какой-то момент вы попадаете в зависимость root. Для проекта с разными компонентами это означает введение компонента root. Это компонент - в вашем случае stati c lib - как и любой другой, который содержит структуры данных и функциональные возможности, необходимые и / или полезные для всей системы. Сложность состоит в том, чтобы не позволить этому компоненту стать шкафом под кухонной раковиной - ведь теперь у вас есть удобное место для размещения вещей, не думая о том, где они действительно принадлежат. Но это проблема людей, а не техническая.

Обычно я называю цель CMake для библиотеки компонентов root projectname_core. Раньше я помещал все его содержимое в пространство имен projectname::core. Но оказалось, что все в команде просто писали using namespace projectname::core; везде. Очевидно, что дополнительное пространство имен не добавляет никакой полезной информации, и размещение всей системы в пространстве имен projectname также работает. Вот что я делаю в эти дни.

Answer 2

Это моя область знаний. Я создатель POWER, архитектуры программного обеспечения, которая моделирует производство. Вы можете прочитать мой пост о DTO здесь, так как я вышел за рамки простых закодированных. Что такое объект передачи данных?

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

Технически процессы никогда не должны совместно использовать DTO, даже если DTO очень похожи или даже структурно эквивалентны. Совместное использование модулей или даже DTO создает сложность централизации - недостаток организации, который я здесь авторитетно описываю, используя Harvard Business Review в качестве источника: http://www.powersemantics.com/p.html