在这种情况下我应该使用嵌套类吗？

Question

我正在研究用于视频播放和录制的类集合。我有一个主类，其行为类似于公共接口，其方法如下 play(), stop(), pause(), record() ETC...然后我有主力类来执行视频解码和视频编码。

我刚刚了解到 C++ 中嵌套类的存在，我很想知道程序员如何看待使用它们。我有点谨慎，不太确定其优点/缺点是什么，但它们似乎（根据我正在阅读的书）可用于像我这样的情况。

这本书建议，在像我这样的场景中，一个好的解决方案是将主力类嵌套在接口类中，这样客户端不打算使用的类就没有单独的文件，并避免任何可能的命名冲突？我不知道这些理由。嵌套类对我来说是一个新概念。只是想看看程序员如何看待这个问题。

Answer 1

我有点不愿意在这里使用嵌套类。如果您为“多媒体驱动程序”创建一个抽象基类来处理后端内容（主力），并为前端工作创建一个单独的类，会怎么样？前端类可以采用指向已实现的驱动程序类的指针/引用（针对适当的媒体类型和情况）并对主力结构执行抽象操作。

我的理念是继续以一种完美的方式让客户可以访问这两种结构，前提是它们将同时使用。

我会参考类似的东西 QText文档 在 Qt 中。您为裸机数据处理提供直接接口，但将权限传递给 QTextEdit 等对象来执行操作。

Answer 2

您可以使用嵌套类来创建实现主类所需的（小）辅助类。或者例如，定义一个接口（具有抽象方法的类）。

在这种情况下，嵌套类的主要缺点是这使得重用它们变得更加困难。也许您想在另一个项目中使用 VideoDecoder 类。如果将其设为 VideoPlayer 的嵌套类，则无法以优雅的方式执行此操作。

相反，请将其他类放在单独的 .h/.cpp 文件中，然后您可以在 VideoPlayer 类中使用它们。VideoPlayer 的客户端现在只需要包含声明 VideoPlayer 的文件，并且仍然不需要知道您是如何实现它的。

Answer 3

决定是否使用嵌套类的一种方法是考虑该类是否扮演支持角色或它自己的角色。

如果它的存在只是为了帮助另一个类，那么我通常将其设为嵌套类。对此有很多警告，其中一些似乎是矛盾的，但这一切都取决于经验和直觉。

Answer 4

听起来像是你可以使用的情况 策略模式

Answer 5

有时，对用户隐藏实现类是适当的——在这些情况下，最好将它们放在 foo_internal.h 中，而不是放在公共类定义中。这样，您的 foo.h 的读者将不会看到您希望他们不被困扰的内容，但您仍然可以针对接口的每个具体实现编写测试。

Answer 6

我们遇到了半旧的 Sun C++ 编译器和嵌套类的可见性问题，其行为在标准中发生了变化。当然，这并不是不执行嵌套类的原因，只是如果您计划在包括旧编译器在内的许多平台上编译软件，则需要注意这一点。

Answer 7

好吧，如果您在 Interface 类中使用指向主力类的指针，并且不在接口方法中将它们公开为参数或返回类型，则不需要在接口头文件中包含这些主力类的定义（您只需改为向前声明它们）。这样，界面的用户将不需要了解后台的类。

您绝对不需要为此嵌套类。事实上，随着项目的增长，单独的类文件实际上将使您的代码更具可读性并且更易于管理。如果您需要子类化（例如不同的内容/编解码器类型），它也会在以后为您提供帮助。

以下是有关以下内容的更多信息 PIMPL模式 （第 3.1.1 节）。

Answer 8

仅当无法使用可能的外部类的公共接口将内部类实现为单独的类时，才应使用内部类。内部类增加了类的大小、复杂性和责任，因此应谨慎使用它们。

您的编码器/解码器类听起来更适合 策略模式

Answer 9

避免嵌套类的原因之一是，如果您打算用 swig (http://www.swig.org) 与其他语言一起使用。Swig 目前在嵌套类方面存在问题，因此与公开任何嵌套类的库进行交互变得非常痛苦。

Answer 10

另一件需要记住的事情是您是否曾经设想过工作功能的不同实现（例如解码和编码）。在这种情况下，您肯定需要一个具有实现功能的不同具体类的抽象基类。为每种类型的实现嵌套一个单独的子类实际上并不合适。