Списки атрибутов или наследование джунглей?

Question

У меня есть 2 приложения (назовем их AppA и AppB), взаимодействующих друг с другом.
AppA отправляет объекты в AppB.
Могут быть разные объекты, и AppB не поддерживает каждый объект.Объектом может быть Модель (например, игра, в которой модели - это транспортные средства, дома, люди и т. Д.).
Могут быть разные AppB.Каждый поддерживает другую базу объектов.
Например, может существовать AppB, который просто поддерживает модели транспортных средств.Другой AppB просто поддерживает определенные модели самолетов.

Текущий случай следующий:

Существует BasicModel, который имеет положение и ориентацию.

Если другойпользователю нужны дополнительные атрибуты, он наследует ExpandedModel.И добавляет, например, атрибут Color.
Теперь каждый пользователь, которому нужны дополнительные атрибуты, наследует от более общей модели.Через некоторое время появляется VehicleModel, который может активировать стеклоочистители, AircraftModel, который может иметь посадочные огни, или PersonModel, который может махать на прощание, если для определенного логического значения установлено значение true.

AppB всегда нужно настраивать, если он должен поддерживать новую модель.

Этот подход имеет большой недостаток: он становится чрезвычайно сложным после нескольких наследований.Возможно, существуют избыточности, такие как ExpandedAircraftModel, в которых тоже можно использовать стеклоочистители.

Другой подход:

Я создаю только один Model -класс, имеющий список атрибутов.Наиболее простой реализацией была бы std :: map, где Key - это имя-атрибута, а Value - это значение-атрибута.
Теперь пользователь может вводить столько информации, сколько ему нужно.Если он хочет использовать стеклоочиститель, он просто добавляет "windshieldwiper - ON" -пару.

Если AppB поддерживает стеклоочистители, он просто смотрит, есть ли такой атрибут в списке, и считывает соответствующее значение.

Разработчик AppB должен хорошо документировать, какие атрибуты он поддерживает.Каждый разработчик должен проверить, существует ли уже определенный атрибут и как он называется (например, один разработчик может назвать свой атрибут windshieldwiper, а другой - windshield-wiper)
Это также может быть очень сложным, и единственное, чтопользователь может обратиться к документации или конкретной спецификации стандарта, которые должны храниться в центральном пространстве.

Наконец, вопрос:

Какой подход лучше?
Вамувидеть какие-либо дополнительные недостатки?
Есть ли третий подход, который следует использовать вместо этих двух?

Answer 1

Для сравнения, в протокольных буферах Google используется комбинация обоих вариантов, но он сильно склоняется ко второму примеру.

Если у вас есть отчетливо разные данные, которые необходимо отправить по каналу, вы используете инструмент для генерации производной от класса «message», но каждое сообщение может содержать другие сообщения, и вы можете вкладывать определения сообщений в себя. Когда сообщение отправляется, получатель проверяет поля, чтобы определить, к какому типу оно относится и какие поля содержатся в нем.

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