Hana 通过标签调度来定制行为的机制能否被视为一种适配器模式？

如何解决Hana 通过标签调度来定制行为的机制能否被视为一种适配器模式？

tl;博士

对boost::hana::transform 的std::vector 定制（通过为标签boost::hana::tranform_impl 专门化ext::std::vector）是一种适配器模式 将 STL 的 std::transform 包装到 Hana 的接口函数 boost::hana::transform 中？

为什么要问这个问题

我正在阅读 Dive into Design Patterns，但我有点担心这个资源，就像我一直在窥视的任何其他资源（包括 Head First - Design Patterns）一样，没有一个页面，甚至可能不是一个段落，不包含 inheritance/virtual/extend/ 等词，就像继承一样理解和使用设计模式的唯一途径。

为了减少对这些臭名昭著的模式的继承偏见的理解，我试图从其他角度看待它们，通过询问它们在像 Haskell 这样的函数式编程语言中的样子（例如 {{3 }})，或者，对于目前的问题，如果在使用大量模板元编程（例如 this question）的库中使用这种模式。

问题

如果您查看 Boost.Hana，有一些（已注释的）代码可以按照 Hana 定义的方式使 std::vector 成为函子，即通过专门用于 {{1} 的 transform_impl 模板}}（嗯，实际上对于与任何 std::vector 相关联的标签 ext::std::vector）。

专业化显然诉诸std::vector<T>（和一些模板技巧/std::transform）来完成工作。

然而，最终效果是，如果我取消注释该代码，那么我就可以在 enable_if 上使用 boost::hana::transform，如果不取消该代码的注释，我就无法做到这一点。

另一方面，无论我是否拥有 std::vector，std::vector 在概念上都是一个函子。实际上，boost::hana::transform 存在于 STL 中，“唯一”的缺点是它不能以函数方式使用，因为它是基于迭代器的。

因此，在我看来，为 std::transform 定制 boost::hana::transform（通过为标签 std::vector 专门化 boost::hana::tranform_impl）有点像将 STL 接口适配到函子， ext::std::vector，到 Hana 的界面，std::transform。

这是一个有效的解释吗？

代码

/usr/include/boost/hana/ext/std/vector.hpp 是受 Here 启发的用例和解决方案。

linked open source book 与我使用（希望正确） Hana 方法来解决它的用例相同。既然它解决了同样的问题，我很想自我回答，这确实是适配器模式的一种情况。