我应该在这种情况下使用嵌套类吗？
我正在处理用于视频回放和录制的类的集合。我有一个类似公共接口的主类，使用的方法有play(),,record()等等。然后我有用于视频解码和视频编码的主力类。我应该在这种情况下使用嵌套类吗？
我刚刚了解到C++中嵌套类的存在，我很想知道程序员是怎么想的。我有点警惕，并不确定它的好处/缺点，但它们似乎（根据我正在阅读的书）将用于像我这样的情况。
这本书提出，在像我这样的场景中，一个好的解决方案是将嵌套在接口类中的劳动力类，所以没有单独的客户端不打算使用的类的文件，并且为了避免任何可能的命名冲突？我不知道这些理由。嵌套类对我来说是一个新概念。只是想看看程序员对这个问题的看法。
我会有点不情愿在这里使用嵌套类。如果您为“多媒体驱动程序”创建抽象基类以处理后端工作（主力），并为前端工作创建单独的类，那该怎么办？前端类可以采用指向/实现的驱动程序类的引用（适用于适当的介质类型和情况），并在主马结构上执行抽象操作。
我的理念是继续努力，让客户能够以优美的方式接触到这两种结构，就在他们将一起使用的假设下。
我会在Qt中引用类似于QTextDocument的东西。您提供了裸机数据处理的直接界面，但将权限传递给像QTextEdit这样的对象来完成操作。
决定是否使用嵌套类的一种方法是考虑这个类是否扮演支持角色或它自己的角色。
如果它仅用于帮助另一个类的目的，那么我通常会将它作为一个嵌套类。对此有一些警告，其中一些看起来矛盾，但一切都归结为经验和直觉。
有时候，适当的对用户隐藏实现类的情况下 - 在这种情况下，最好把它们放在一个foo_internal.h不是公共类定义中。这样，你的foo.h的读者就不会看到你不喜欢的东西，但是你仍然可以针对你的界面的每个具体实现编写测试。
您将使用嵌套类来创建实现主类所需的（小）辅助类。或者例如，定义一个接口（一个具有抽象方法的类）。
在这种情况下，嵌套类的主要缺点是这使得难以重用它们。也许你想在另一个项目中使用VideoDecoder类。如果你使它成为VideoPlayer的一个嵌套类，你不能以优雅的方式做到这一点。
相反，将其他类放在单独的.h/.cpp文件中，然后您可以在VideoPlayer类中使用它们。 VideoPlayer的客户端现在只需要包含声明VideoPlayer的文件，但仍然不需要知道如何实现它。
只有在无法使用可能的外部类public interface将其实现为单独的类时，才应该使用内部类。内部类增加了类的大小，复杂性和责任，所以应该谨慎使用它们。
您的编码器/解码器类听起来更符合Strategy Pattern
我们遇到了一个半旧的Sun C++编译器和嵌套类的可见性问题，该问题在标准中发生了变化。当然，如果你打算在包括旧编译器在内的许多平台上编译你的软件，那么这不是不要做你的嵌套类的理由。
要记住的另一件事是，你是否设想你的工作功能（如解码和编码）的不同实现。在这种情况下，你肯定会想要一个具有不同具体类的抽象基类来实现这些功能。为每种类型的实现嵌套一个单独的子类是不合适的。
那么，如果您在Interface类中使用指向您的主力类的指针，并且不要在接口方法中将它们作为参数或返回类型公开，则不需要在接口头中包含这些工作马的定义文件（你只需要转发声明他们）。这样，你的界面的用户将不需要知道背景中的类。
你绝对不需要为此嵌套类。实际上，随着项目的增长，单独的类文件实际上会使您的代码更易读，更易于管理。如果您需要继承子类（比如说不同的内容/编解码器类型），它也将在以后帮助您。
以下是关于PIMPL pattern（3.1.1节）的更多信息。