标记容器 - 模仿容器的界面是一种好的做法吗？

Tagged container - is mimicking the container's interface a good practice?

本文关键字：一种 界面      更新时间：2023-10-16

假设我有一个容器类型，我想附加附加信息。我的方法是定义一个包含容器和信息的类。为新类定义模仿容器方法的方法是一种好的做法吗？例如，我想写myContainerObject[i]，而不是写myContainerObject.internalVector[i]。人们必须重新定义每个想要使用的方法（size(), push_back()等）。这种方法的缺点是什么？存在哪些替代方案（例如，从容器继承是更好的解决方案吗？）。

您正在使用带有转发函数的组合，使用STL容器等具体类是正确的做法。一个缺点是，您必须重新定义想要允许的每个函数的每个重载，仅用于转发参数以及鹦鹉typedef嵌套类型（如iterator）。

另一种选择是继承，但从不公开，只使用私有继承（因为STL容器的析构函数是公共和非-虚拟的），然后在自定义类内使用声明将基类函数和类型的名称带入作用域（函数的所有重载只需要一个using Base::name;）。

获取容器类型的可能方法，我可以想到：

  1. 提供一个decorator（这就是您所询问的），其组件将是内部容器。当您有必须遵守的严格接口时，这是可行的。这既不是好的做法，也不是坏的做法。阅读装饰器设计模式。

  2. 在算法中使用迭代器概念，而不是容器。这是一种通用方法，以及stl算法是如何实现的

  3. 使用容器概念-类似于（2）。检测该类型是否为容器（SFINAE技巧）并对其进行操作。

  4. 重新实现容器接口。你需要一个非常有力的理由来做这件事，因为这需要大量的工作/专业知识。一些信息：http://stdcxx.apache.org/doc/stdlibug/16-3.html

一般来说，除非您的用例非常、非常琐碎，或者您有一些特定的需求，否则您不应该将类内部状态（myContainerObject.internalVector[i]）公开到外部世界。

最佳实践是保持内部私有，并实现[] operator和其他功能（size()等）。

相关文章：