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

我正在研究用于video回放和录制的类的集合。 我有一个像公共接口一样的主类，有play() ， stop() ， pause() ， record()等方法。然后我有一些主要的类来完成video解码和video编码。

我刚刚学习了C ++中嵌套类的存在，我很想知道程序员是怎么想的。 我有点小心翼翼，不确定它的好处/缺点，但是根据我正在阅读的书，它们似乎被用在我的例子中。

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

Answer 1

我会有点不情愿在这里使用嵌套类。 如果您为“多媒体驱动程序”创build抽象基类以处理后端工作（主力），并为前端工作创build单独的类，那该怎么办？ 前端类可以采取指针/引用实施的驱动程序类（适当的媒体types和情况），并在主力结构上执行抽象操作。

我的理念是继续前进，使客户能够以优美的方式访问这两个结构，只是假设他们将被联合使用。

我会在Qt中引用类似QTextDocument的东西。 您提供了裸机数据处理的直接接口，但将权限传递给像QTextEdit这样的对象来执行操作。

Answer 2

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

在这种情况下，嵌套类的主要缺点是这使得难以重用它们。 也许你想在另一个项目中使用VideoDecoder类。 如果你使它成为一个VideoPlayer的嵌套类，你不能以优雅的方式做到这一点。

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

Answer 3

决定是否使用嵌套类的一种方法是考虑这个类是否起辅助作用或者是自己的一部分。

如果仅仅是为了帮助另一个class级而存在，那么我通常会把它变成一个嵌套的class级。 对此有一些警告，其中一些看起来矛盾，但一切都归结为经验和直觉。

Answer 4

那么，如果你在你的Interface类中使用指向你的主力类的指针，并且不要在接口方法中将它们作为参数或返回types公开，那么你就不需要在接口头文件中包含这些工作马的定义转发宣告他们）。 这样，你的界面的用户将不需要知道在后台的类。

你绝对不需要为此嵌套类。 实际上，随着项目的增长，单独的类文件实际上会使您的代码更易读，更容易pipe理。 如果您需要inheritance子类（比如说不同的内容/编解码器types），它也将在以后帮助您。

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

Answer 5

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

Answer 6

有时将用户的实现类隐藏起来比较合适 – 在这种情况下，最好将它们放在foo_internal.h中，而不要放在公共类定义中。 这样，你的foo.h的读者就不会看到你不喜欢的东西，但是你仍然可以针对你的接口的具体实现编写testing。

Answer 7

我们遇到了一个半旧的Sun C ++编译器的问题，并且在标准中改变了行为的嵌套类的可见性。 当然，如果你打算在包括旧编译器在内的许多平台上编译你的软件，那么这并不是你做嵌套类的理由。

Answer 8

只有当你不能将它作为一个单独的类使用可能的外部类public interface来实现时，才应该使用内部类。 内部类增加了一个类的大小，复杂性和责任，所以他们应该谨慎使用。

您的编码器/解码器类似乎更适合战略模式

Answer 9

避免嵌套类的一个原因是，如果您打算用swig（ http://www.swig.org ）封装代码以便与其他语言一起使用。 Swig目前存在嵌套类的问题，因此与暴露任何嵌套类的库进行接口变成了一个真正的痛苦。

Answer 10

另外要记住的是，你是否设想过你的工作function的不同实现（例如解码和编码）。 在这种情况下，你肯定会想要一个具有不同具体类的抽象基类来实现这个function。 为每种types的实现嵌套一个单独的子类是不合适的。