Дизайн на основе политик: как правильно настроить структуру хоста?

У меня есть куча алгоритмов и коллекций, и я использую дизайн на основе политики (см. Книгу Современный дизайн C ++) иметь дело с произвольной комбинаторной сложностью. Это здорово, но для того, чтобы предотвратить разрушение класса Host с помощью указателя на политику, 1 предлагает сделать деструкторов охраняемых. Однако, если я сделаю защищенными деструкторы Algorithm и Collection, я не смогу использовать их самостоятельно, но только в качестве политик. Кроме того, я не вижу преимуществ дизайна на основе политик по сравнению с общим шаблоном фабрики …

Вот модель кода:

#include <iostream>

template<class Collection>
class AlgorithmOne
{
public:
void doSomethingWithData(Collection& data)
{
// Use Collection iterators to build up an algorithm.
}
};

template<class Collection>
class AlgorithmTwo
{
public:
void doSomethingWithData(Collection& data)
{
// Use Collection iterators to build up an algorithm.
}
};

template<class Collection>
class AlgorithmThree
{
public:
void doSomethingWithData(Collection& data)
{
// Use Collection iterators to build up an algorithm.
}
};template<class Element>
class CollectionOne
{
public:
typedef Element ElementType;

};

template<class Element>
class CollectionTwo
{
public:
typedef Element ElementType;

};

template<class Element>
class CollectionThree
{
public:
typedef Element ElementType;

};

template<typename HostTraits>
class HostInheritsData
:
public HostTraits::Collection,
public HostTraits::Algorithm
{
public:
typedef HostTraits Traits;

using Traits::Algorithm::doSomethingWithData;

void doSomethingWithData()
{
doSomethingWithData(*this);
}
};

template<typename HostTraits>
class HostCompositsData
:
public HostTraits::Algorithm
{
typename HostTraits::Collection data_;

public:
typedef HostTraits Traits;

using Traits::Algorithm::doSomethingWithData;

void doSomethingWithData()
{
doSomethingWithData(data_);
}

// Clumsy and breaking encapsulation
typename HostTraits::Collection& data()
{
return data_;
}
};

template<typename HostTraits>
class GenericStrategy
{
typename HostTraits::Collection data_;
typename HostTraits::Algorithm algorithm_;

public:

void doSomethingWithData()
{
algorithm_.doSomethingWithData(data_);
}
};

class ElementOne {};
class ElementTwo {};
class ElementThree {};

struct MyConfig
{
typedef ElementOne                  Element;
typedef CollectionThree<Element>      Collection;
typedef AlgorithmOne<Collection>  Algorithm;
};

int main(int argc, const char *argv[])
{
HostInheritsData<MyConfig> hostInherits;
hostInherits.doSomethingWithData();

// This must be a mistake, are policies meant to be used this way?
hostInherits.doSomethingWithData(hostInherits);

HostCompositsData<MyConfig> hostComposits;
hostComposits.doSomethingWithData();

// Clumsy to use, not intuitive and breaking encapsulation.
hostComposits.doSomethingWithData(hostComposits.data());

// Combinatorics are there, I can combine whatever I want in MyConfig as for
// policies, but I can also have global Algorithm and Collection objects
// (no protected destructors).
GenericStrategy<MyConfig> strategy;
strategy.doSomethingWithData();

return 0;
}

Вот мои вопросы:

Я настраиваю структуру класса Host с помощью политик. Как я могу полностью обогатить интерфейс класса Host, когда каждый реалистичный Алгоритм требует для работы Collection, а Collection инкапсулируется в хост?

Когда я сравниваю основанный на политике дизайн вместе с универсальной фабрикой, разве универсальная фабрика не приносит мне ту же комбинаторную сложность? Кажется, что использование Generic Factory лучше, так как я могу поменять Element, Container и Algorithm во всех возможных комбинациях, и у меня все еще могут быть открытые деструкторы для всех политик, что позволяет мне комбинировать их любым способом, например, как я хочу. глобальная комбинация Элемент, Коллекция и Алгоритм.

Мне кажется, что Расширенные Политики становятся проблемой, как только структура настроена. Даже если позже я добавлю функцию-член к алгоритму, он, вероятно, будет иметь параметры, относящиеся к Collection (например, итераторы Collection): если Хост инкапсулирует Collection с использованием композиции, мне нужно запросить его для параметра его собственной функции-члена:

// Clumsy to use, not intuitive and breaking encapsulation.
hostComposits.doSomethingWithData(hostComposits.data());

и если Хост инкапсулирует Коллекцию с использованием наследования, он становится (по крайней мере для меня) еще более странным:

 // This must be a mistake, are policies meant to be used this way?
hostInherits.doSomethingWithData(hostInherits);

Полностью ли я неправильно понял дизайн, основанный на политике (еще раз), правильно ли я использую черты?
Является ли шаблон общей стратегии лучшим выбором в этом случае?