基于策略的设计:如何以合适的方式定制主机结构

我有一堆算法和集合，我正在使用基于策略的设计(参见《现代c++设计》一书)来处理任意组合的复杂性。这很好，但是为了防止使用指向策略的指针破坏Host类，我建议将受策略保护的析构函数设置为protected。然而，如果我使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;
}

以下是我的问题:

我正在使用策略自定义宿主类的结构，当每个实际的算法都需要一个集合来工作，并且集合被封装在宿主中时，我如何才能真正丰富宿主类的接口?

当我比较基于策略的设计和通用工厂时，通用工厂不是给我带来了相同的组合复杂性吗?似乎使用通用工厂是更好的，因为我可以在所有可能的组合中交换元素，容器和算法，我仍然可以为所有策略提供公共析构函数，这允许我以任何我想要的方式组合它们，例如元素，集合和算法的全局组合。

在我看来，一旦结构被定制，富集策略就会成为一个问题。即使我稍后向算法添加成员函数，它也可能有与Collection相关的参数(例如Collection迭代器):如果Host使用复合封装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); 

我是否完全误解了基于策略的设计(又一次)，我是否正确使用了这些特征?在这种情况下，通用策略模式是更好的选择吗?