此文档参考自：https://gracicot.github.io/conceptmodel/2017/09/13/concept-model-part1.html ，觉得很有趣，就翻译过来了

一、Concept-Model：多态的新视角

面向对象编程大家都很熟悉，只需实现一个接口 Interface 。但这种使用经典 OOP 实现的多态性是侵入性的，即使在真正不需要的地方也会强制多态行为，比如总会触发堆分配，伴随着一个包含基类的列表。今天我们要介绍一种新的概念模型（ Runtime Concept 或 Virtual Concept ），这是一种可能会改变你对多态性及其试图解决的问题的看法的模型。
让我们从一个简单的例子开始：样例中有一个接口 abstract_task ，一个或多个实现（即 print_task ），一个类型擦除列表 tasks，以多态方式执行该 process 函数。

// Our interface.
struct abstract_task {
    virtual void process() = 0;
    virtual ~abstract_task() = default;
};

// An implementation of our interface.
struct print_task : abstract_task {
    void process() override {
        std::cout << "Print Task" << std::endl;
    }
};

// A type erased list of tasks.
std::vector<std::unique_ptr<abstract_task>> tasks;

// A function that push a new task in the list.
void push(std::unique_ptr<abstract_task> task) {
    tasks.emplace_back(std::move(task));
}

// execute all tasks and clear the list.
void run() {
    for(auto&& task : tasks) {
        task->process();
    }
    
    tasks.clear();
}

上面的代码符合我们大部分的编程直觉。首先，这里需要动态分配，且没有办法解决它。但真实意图不是“我们想要 100% 的时间进行动态分配！” ，真实意图是“我们想要一个类型擦除的任务列表”。然而，始终通过动态分配和多态恰好是最常见的方式，而且它也是语言自动实现多态的唯一方式。
其次，它不适用于所有类，很多人可能会说：

是的，只需实现该接口即可！所有类型都有效！

问题是，并非所有类型都可以继承 abstract_task 。假设有这样一个类：

struct some_library_task : library_task {
    void process() { /* ... */ }
};

且要求你不能更改该类，你必须实现一个 Adaptor 才能使其在代码中工作。
此外，还有另一种类不可能扩展接口：lambdas 。是的，lambda ！你的代码可能与他们不兼容！想象一下写这样的东西：

push([] { std::cout << "print something!"; });

遗憾的是，这行不通，因为 lambda 不是动态分配的，也不会扩展类 abstract_task 。
Concept-Model 惯用法旨在解决这些问题，我们来具体是怎么实现的。

二、Concept-Model: The adapter pattern on steroids

在本节中，我们将解释从经典 OOP 到 Concept-Model 的迁移过程。将会分解为许多小步骤，以便更容易理解。
首先，函数 push 接受一个 std::unique_ptr。想象一下，假如你有几十个函数以这种方式执行任务，如果有一天你需要所有那些采用 std::unique_ptr<abstract_task> 原始指针或引用的函数怎么办？我们先从这一点入手：取而代之的是包含指针的结构：

struct task {
    task(std::unique_ptr<abstract_task> t) noexcept : wrapped{std::move(t)} {}

    std::unique_ptr<abstract_task> wrapped;
};

// A vector of task, which wrap a unique pointer.
std::vector<task> tasks;

// We take a task by value, since it's constructible from a unique pointer.
void push(task t) {
    tasks.emplace_back(std::move(t));
}

但现在还是有些问题，some_task.wrapped->process()的用法会很难受，继续调整：

struct task {
    task(std::unique_ptr<abstract_task> t) noexcept : wrapped{std::move(t)} {}
    
    void process() {
        wrapped->process();
    }
    
private:
    std::unique_ptr<abstract_task> wrapped;
};

void run() {
    for(auto&& task : tasks) {
        task.process();
    }
    
    tasks.clear();
}

现在已经很不错了！对于任何地方 std::unique_ptr<abstract_task> ，你都可以放到 tasks里（隐式构造），且是 pass-by-value 。

push(std::make_unique<print_task>());

但是等等……这并没有解决我们的问题！我们想要支持 lambda，改变对象的发送方式，避免堆分配，这真的有用吗？

当然！在该列表中，我们现在可以做一件事：改变传递对象的方式。无需更改 200 个函数签名，我们只需更改 task 的构造函数。
现在，希望 push 函数能够接收 some_library_task 。为此，我们需要一个 Adaptor 来使这些类型适应接口abstract_task：

// Our adapter. We contain a library task and implementing the abstract_task interface
struct some_library_task_adapter : abstract_task {
    some_library_task_adapter(some_library_task t) : task{std::move(t)} {}

    void process() override {
        task.process();
    }
    
    some_library_task task;
};

struct task {
    task(std::unique_ptr<abstract_task> t) noexcept : wrapped{std::move(t)} {}
    
    // We can now receive a library task by value.
    // We move it into a new instance of adapter.
    task(some_library_task t) noexcept :
        wrapped{std::make_unique<some_library_task_adapter>(std::move(t))} {}
    
    void process() {
        wrapped->process();
    }
    
private:
    std::unique_ptr<abstract_task> wrapped;
};

int main() {
    // push a new task to the vector
    push(some_library_task{});
}

到此，我们可以通过 pass-by-value 方式来 push 未继承 abstract_task 的 some_library_task 对象。
但是，那些继承自 abstract_task 的 task 还不能 pass-by-value，而必须使用 ptr。因此，我们需要将为每个类创建一个 Adaptor， 但我们不希望任何外部类扩展 abstract_task，因此它将是一个私有成员类型：

struct task {
    task(some_library_task task) noexcept :
        self{std::make_unique<library_model_t>(std::move(t))} {}
    task(print_task task) noexcept :
        self{std::make_unique<print_model_t>(std::move(t))} {}
    task(some_other_task task) noexcept :
        self{std::make_unique<some_other_model_t>(std::move(t))} {}
    
    void process() {
        self->process();
    }
    
private:
    // This is our interface, now named concept_t instead of abstract_task
    struct concept_t {
        virtual ~concept_t() = default;
        virtual void process() = 0;
    };
    
    // We name our struct `model` instead of `adapter`
    struct library_model_t : concept_t {
        library_model_t(some_library_task s) noexcept : self{std::move(s)} {}
        void process() override { self.process(); }
        some_library_task self;
    };
    
    struct print_model_t : concept_t {
        library_model_t(print_task s) noexcept : self{std::move(s)} {}
        void process() override { self.process(); }
        print_task self;
    };
    
    struct some_other_model_t : concept_t {
        library_model_t(some_other_task s) noexcept : self{std::move(s)} {}
        void process() override { self.process(); }
        some_other_task self;
    };
 
    // We quite know it's wrapped. Let's name it self
    std::unique_ptr<concept_t> self;
};

这太荒谬了！我们总不能为所有的 abstract_task 的派生类都复制一份构造函数，以及继承 concept_t的子类代码。

的确，C++ 中有一个很棒的工具，它经过精心设计，可以避免无意识的复制粘贴：模板！

struct task {
    template<typename T>
    task(T t) noexcept : self{std::make_unique<model_t<T>>(std::move(t))} {}
    
    void process() {
        self->process();
    }
    
private:
    struct concept_t {
        virtual ~concept_t() = default;
        virtual void process() = 0;
    };
    
    template<typename T>
    struct model_t : concept_t {
        model_t(T s) noexcept : self{std::move(s)} {}
        void process() override { self.process(); }
        T self;
    };

    std::unique_ptr<concept_t> self;
};

int main() {
    // natural syntax for object construction! Yay!
    push(some_library_task{});
    push(my_task{});
    push(print_task{});
}

问题解决了！我们代码的 API 中不再有复制粘贴，不再有继承，不再有指针！

三、Conclusion

这个 Concept-Model 是如何解决我们在开头列出的所有问题？
首先，它可以自然地应用多态性，与其他代码看起来很统一，语法也更简洁。

void do_stuff() {
    // Initialize a std::string using a value in direct initialization 
    std::string s{"value"};
    
    // Pretty similar syntax eh?
    task t{print_task{}};
    
    // Or if you like AAA style
    auto s2 = std::string{"potato"};
    auto t2 = task{print_task{}};
    
    // use string like this
    auto size = s.size();
    
    // use task like that. Again, pretty similar 
    t.process();
}

没有箭头，没有 new ，没有std::make_*。所有的多态性隐藏在实现细节中，潜在的生效的。其次，它避免了堆分配。是的，即使我们在内部通过唯一指针传递我们的对象。

void do_stuff() {
    some_task t;
    
    // do some stuff with task
    t.stuff();
    
    // maybe push the task
    if (condition()) {
        push(std::move(t));
    }
}

在上面示例中，t有条件地被推入列表。如果我们不需要堆分配和多态性，我们可以在运行时决定不使用它。还有其他策略，比如使用 SBO 来避免动态分配，我将在其他部分介绍。
第三，我们的任务实现可以按照 process 自己想要的方式实现功能。例如：

struct special_task {
    int process(bool more_stuff = false) const {
        // ...
    }
};

这仍然满足了这个概念。t.process() 即使函数是常量、接受可选参数或具有不同的返回类型，我们仍然可以调用。