Question

知道这可能是一个不恰当的问题（因为回复可能（将会）仅基于个人主观意见）我仍然冒险要求：

我们编写了一些代码并提出了以下构造

#include <iostream>
#include <string>

class Generic
{
public: virtual void do_work() = 0;
};

class SomeAppDescriptor : public Generic
{
public: static std::string name() { return "SomeAppDescriptor"; }
};

template <class TGenericApp> 
class CommonFunctionalities : public TGenericApp
{
public: void do_common_work() {
            std::cout << "do_common_work for " << TGenericApp::name();
        }
};

class RealClass : public CommonFunctionalities<SomeAppDescriptor>
{
public: virtual void do_work() {
            do_common_work();
            std::cout << "and doing the work" << std::endl;
        }
};

int main(int argc, char const *argv[])
{
    RealClass a;
    a.do_work();
    return 0;
}

现在我们处于文档阶段......我们需要为CommonFunctionalities继承自模板成员的构造提供一个名称...并使用{{1}的属性这实际上是模板成员...如果你要命名这个构造，那么它的名称是什么？

修改

主要的想法是有很多SomeAppDescriptor类从配置文件（名称，IP，数据库等等）读取一些数据，并且有一个中间层（这里代表它）通过AppDescriptor完成工作（但在某些模糊的地方，CommonFunctionalities对象被映射到CommonFunctionalities（字符串和通用的映射），以便获得{{1的功能最后，来自某个地方的某个人正在调用name()的{{1}}，该do_work()是在一组“上层”图层类（do_work）中实现的

Answer 1

对我来说，这看起来就像Decorator的拙劣尝试。

SomeAppDescriptor和CommonFunctionalities不会覆盖do_work，因此无需继承Generic;然而do_common_work的使用暗示可能有用。
如果RealClass直接从Generic继承，则可以通过撰写CommonFunctionalities。

使用装饰器模式，我最终得到：

class Generic { public: virtual void do_work() = 0; };

template <typename App>
class CommonFunctionalities: public Generic {
public:
    virtual void do_work() override {
        std::cout << "CommonFunctionalities - " << App::name() << "\n";
    }
};

class RealClass: public Generic {
public:
    RealClass(std::unique_ptr<Generic> p): previous(std::move(p)) {}

    virtual void do_work() override {
        if (previous) { previous->do_work(); }
        std::cout << "RealClass\n";
    }

private:
    std::unique_ptr<Generic> previous;
};

int main() {
    RealClass rc{std::make_unique< CommonFunctionalities<SomeAppDescriptor> >()};

    Generic& g = rc;
    g.do_work();

    return 0;
}

Decorator是专门创建的，用于分层工作，没有任何类知道多于接口类，因此您可以在运行时选择要使用的层。即使不需要运行时灵活性，使用此方法仍然有利，因为它减少了依赖性：RealClass不知道CommonFunctionalities。

注意：在C ++中，由于模板，您也可以在没有接口的情况下使用Decorator方法。

Answer 2

这是Curiously Recurring Template Pattern。

Answer 3

我认为这有点升级到Curiously Recurring Template Pattern。

看起来不错。：）

你会如何命名这个c ++设计模式？

3 个答案: