Решение о построенных объектах во время компиляции

Question

У меня есть следующая проблема для решения.

У меня есть компонент А. Этот компонент имеет некоторые подкомпоненты - B, C, D. Используя cmake, я создаю или не те компоненты B, C, D. Это зависит от конфигурации текущей платформы. Моя система cmake делает исполняемые make-файлы (для компонента A) для связывания только тех компонентов, которые использовались в данном запуске cmake. Если компонент B был построен, он добавляется в исполняемый файл, если нет - не связан. То же самое с другим - C, D.

Все эти компоненты B, C, D предоставляют некоторые реализации интерфейса, используемые в компоненте A. Этот компонент должен управлять объектами, созданными B, C, D, и сохранять эти объекты на некоторой карте, используя надлежащий объект в надлежащее время.

Вопрос:

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

Мне трудно объяснить это. Идея проста - построить некоторую карту этих объектов во время компиляции. Компилируемые компоненты должны доставить свой объект на эту карту.

Answer 1

Я использовал конструкции, похожие на методы реализации Objective-C и Smalltalk.

В C++ методы == функции-члены и должны быть определены во время компиляции. Таким образом, хотя интерфейс может быть расширен с помощью таких механизмов, как препроцессор, такая же конфигурация также должна влиять на любых клиентов класса или просто не будет связываться.

Поэтому я использую систему передачи сообщений для вызова методов объектов. Поэтому, если A является основным классом и вы компилируете в C и D, но не B, тогда процессор сообщений A будет отвечать только на сообщения, которые имеют обработчики, зарегистрированные C и D.

Этот тип дизайна требует наличия система обмена сообщениями. Существует множество существующих систем, таких как буферы протокола Google и Apache Thrift. Я выбрал дизайн, так как я хотел еще больше конфигурации, чем большинство существующих систем (многие из этих систем обмена сообщениями используют IDL-компиляторы).

Однако это позволило мне приблизиться к сфере ОО, чем обычно допускает язык смешанной парадигмы, который обычно разрешает C++.