Здравствуйте. Посоветуйте, как организовать следующую иерархию классов:

     Elevator  Forklift    Crane
          \                |             /
           \               |            /
         AppDependentVehicle
                           |
               GenericVehicle

GenericVehicle реализует обобщённый функционал для любого вида повозок.  Elevator, Forklift, Crane и т.д. - специализации Vehicle для конкретного типа повозки. Предполагается, что эта система классов оформляется в виде библиотеки, которая должна использоваться в различных приложениях.

Есть необходимость добавлять некоторые функции, общие для всех типов повозок (т.е. принадлежащие к Vehicle), но зависимые от конкретного типа приложения, в котором эти классы будут использоваться. Причём набор дополнительных функций не сводится к какому-то стандартному интерфейсу, то есть просто набор предопределённых виртуальных функций здесь не поможет.

Иначе говоря я хочу модифицировать поведение базового класса в зависимости от конкретного приложения, в котором он используется: иметь возможность заменять AppDependentVehicle для конкретного приложения не изменяя производных классов (Elevator и т.д.). В идеальном варианте иметь стандартную библиотеку с GenericVehicle, Elevator, Forkfilft, Crane и для каждого приложения предоставлять собственный AppDependentVehicle.

Реально это?

С уважением

ivans, Да, это абсолютно реально. Наследование и виртуальные функции тебе помогут.

Как мне это поможет? Как я могу замещать AppDependentVehicle не перекомпилируя Elevator,  Forklift,  Crane? Тем более если для каждого приложения описание AppDependentVehicle может радикально отличаться?

А как планируется без компиляции, чтоб Elevator,  Forklift,  Crane узнали об изменениях AppDependentVehicle  ?
Если они от него не зависят, то и ненадо эту функциональность наваливать на базовый класс. 

Реально Elevator должен наследовать напрямую от Vehicle. Но для различных приложений мне нужно расширить именно базовый класс (vehicle), при этом взаимодействие Vehicle <=> Elevator не меняется. Vehicle имеет некоторые виртуальные функции которые предоставляют интерфейс с приложением для базового класса.

какие например ?

вот например можно примерно  так :



Это сообщение отредактировал(а) mes - 22.8.2008, 10:14

Proposed resolution:


Файл с данным кодом поставляем в виде заголовочного файла библиотеки. Для каждого приложения реализуем свой класс AppDependentVehicle. Заголовочный файл библиотеки подлючаем после определения AppDependentVehicle. Для обращения к членам GenericVehicle из AppDependentVehicle можно использовать downcast посредством static_cast.

Это сообщение отредактировал(а) UnrealMan - 22.8.2008, 01:23

Спасибо всем ответившим. Я буду переделывать библиотеку на основе примеров от тов. mes: Vehicle будет просто адаптером к Vehicle implementation. По умолчанию библиотека содержит базовую реализацию VehicleImplementation, которая при необходимости расширяется приложением. Кроме того Vehicle будет предоставлять метод, возвращающий ссылку на текущую implementation для выполнения нестандартных операций, специфичных для приложения.

P.S. Что значит зашоренность! Я на похожие реализации постоянно в qt наталкивался!  Но чтоб применить к собственной программе понадобился совет со сотороны!