C ++设计模式库？

Question

最常见的C ++设计模式库是什么？

我在Alexandrescu的书中读到过Loki库，但现在看起来有点死了。那里有类似的东西吗？

Answer 1

  

“设计模式是针对您的编程语言的错误报告” -   彼得诺维格

为了回答为什么没有很多C ++设计模式库的问题，首先要知道哪些设计模式需要解决。经典的GoF书在序言中说明

  

设计模式描述了针对特定的简单而优雅的解决方案   面向对象软件设计中的问题。

90年代的面向对象编程风格在很大程度上依赖于使用抽象类作为接口，具体实现类来自这些接口。 GoF模式描述了不同类类型的对象之间的创建，结构和行为关系。它们的关键元素是：封装和参数化经常更改的内容。许多GoF模式也可以使用模板重新构造，但是灵活性受限于编译时而不是运行时。

面向对象编程使得添加接口的不同具体实现变得非常容易。 OOP很难为现有界面添加新功能。 Visitor pattern是最好的例子：它本质上是一种解决方案，它依赖于额外的间接层，以允许新算法在现有数据结构上工作。

这与函数式编程完全相反：使用函数式编程可以很容易地为现有数据添加新函数，但是添加这些函数所适用的新数据类型要困难得多。在函数和类型中获得可扩展性的难度称为 expression problem 。

OOP样式多态性主要基于内部多态：动态函数调度基于对象的类型。 Modern C ++还使用外部多态，其中类型擦除等技术允许使用静态接口实现运行时灵活性。新的std::shared_ptr和boost::any或adobe::poly类是这些技术的主要示例。

最近的ACCU presentation by Tobias Darm显示了许多将旧的内部多面体GoF模式转换为这种新的外部多态模式的例子。粗略的想法是用一个函数参数替换抽象类，该参数可以将std::function作为参数。然后std::function从外部控制多态灵活性。通过这种方式，许多GoF模式可以大大增强样板。

TL; DR ：经典的GoF模式是为解决OOP缺点而量身定制的。但是OOP不再是主流的C ++风格。通用编程（标准库，Boost）和OOP的组合可以更优雅地解决许多问题，使得经典设计模式不再是首选解决方案。

Answer 2

设计模式的原始定义是一个可重复使用的方法来解决一个重复出现的问题，该问题可以不方便地封装在库中。因此，在可以将模式封装在库中的那一刻，在我看来，它不再是一种模式。例如，这主要发生在C ++中的迭代器中，因为标准C ++库现在有一个用于实现迭代器的综合框架。

我从来没有尝试过使用Loki，但是阅读Alexandrescu的书，我并不相信基于库的方法真的可以提供很多模式。

Answer 3

可能看起来是重言式，但最常见的是......标准库本身！

它不是 - 严格来说 - 一个“模式库”，而是一个用于解决常见模式实现的工具的文件夹。

请注意，您的问题无法回答，只是一种模式，只是一个常用于各种问题的概念定义。库不提供模式，他们（可以）使用模式（像其他任何人一样）来提供特定问题解决方案的实现。

模式处于比编码更高的抽象层。

Answer 4

为了改善代码可维护性，可重用性和可读性，一些研究人员（如GoF，Booch）开始进行最佳检查实践。他们注意到有经验的开发人员采用了一些模式来解决特定的设计问题。

如您所见，体验创建了设计模式。因此，使用设计模式就像专家一样编码。而且没有银弹。

确实，一些简单的设计模式（如装饰器）可以从特定语言中获得支持。但那是限制。特定于域的框架还指导您使用其接口来完成由这些接口的作者决定的设计模式。

库只会帮助您了解该库中使用的设计模式将如何促进您的实施。它甚至不会让您选择更改设计。