Стратегия упаковки нескольких библиотек в C++

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

class FooX1
{
public:
    void Met1()
    {
        std::cout << "X1\n";
    }
};

class FooX2
{
public:
    void Met1()
    {
        std::cout << "X2\n";
    }
};

Тогда вы можете использовать несколько вариантов.

Вариант 1. Вы можете объявить элемент шаблонного типа и обернуть все вызовы во внешнюю реализацию, даже с некоторой подготовкой перед вызовом. Не забудьте удалить impl в деструкторе ~Foo.

template<typename FooX>
class FooVariant1
{
public:
    FooVariant1()
    {
        impl=new FooX();
    }

    void Met1Wrapper()
    {
        impl->Met1();
    }
private:

    FooX *impl;
};

Применение:

FooVariant1<FooX1> bar;
bar.Met1Wrapper();

Вариант 2. Вы можете наследовать от параметра шаблона. В этом случае вы не объявляете никаких членов, а просто вызываете методы реализации по их именам.

template<typename FooX>
class FooVariant2 : public FooX
{
};

Применение:

FooVariant2<FooX1> bar;
bar.Met1();

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

Если вы хотите, чтобы две реализации сосуществовали во время выполнения, вам подойдет интерфейс (например, вы можете использовать шаблон проектирования фабричных методов для создания экземпляра конкретного объекта, как предложил @n.m.).

Если вы можете решить во время компиляции, какая реализация вам нужна, у вас есть несколько вариантов:

• Все еще используйте интерфейс. Это позволит легко перейти, если в будущем вам понадобятся обе реализации во время выполнения.

• Используйте директивы препроцессора. Здесь нет ничего плохого, если рассматривать C++. Это чисто вопрос дизайна.

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

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

Должен ли тип Foo содержать какую-либо информацию, относящуюся к каждой библиотеке? Если нет, возможно, вы сможете уйти с этим:

#include "Foo.h"

#if defined _FOOXTERNAL1_WRAPPER_
    #include "Foo_impl1.cpp"
#elif defined _FOOXTERNAL2_WRAPPER_
    #include "Foo_impl2.cpp"
#else
    #error "Warn about a missing define here"
#endif

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

Держите Foo абстрактным. Укажите фабричный метод

Foo* MakeFoo();

который выделяет новый объект типа FooImpl1 или FooImpl2 и возвращает его адрес.

Википедия о шаблоне Factory Method.