Should I use nested classes in this case?
我正在研究用于视频播放和录制的类的集合。 我有一个主类，它的作用类似于公共接口，并带有 我刚刚了解了C ++中嵌套类的存在，并且很好奇程序员对使用它们的想法。 我有点警惕，也不太确定好处/缺点是什么，但是(根据我正在阅读的书)它们似乎在诸如我的情况下使用。 该书建议在像我这样的场景中，一个好的解决方案是将主力工作类嵌套在接口类中，这样就没有客户端不打算使用的类的单独文件，并避免任何可能的命名冲突？ 我不知道这些理由。 嵌套类对我来说是一个新概念。 只想看看程序员对这个问题的看法。 我有点不愿意在这里使用嵌套类。如果您为"多媒体驱动程序"创建了一个抽象基类来处理后端的东西(主力)，而为前端工作创建了一个单独的类怎么办？前端类可以采用指向已实现的驱动程序类的指针/引用(针对适当的媒体类型和情况)，并在主力结构上执行抽象操作。 我的理念是继续进行工作，使两种结构都以优美的方式为客户所用，只是假设它们可以串联使用。 我会在Qt中引用类似QTextDocument的东西。您提供了裸机数据处理的直接接口，但是将权限传递给QTextEdit之类的对象来进行操作。 您将使用嵌套类来创建实现主类所需的(小型)帮助程序类。或例如，定义一个接口(带有抽象方法的类)。 在这种情况下，嵌套类的主要缺点是这使得重用它们更加困难。也许您想在另一个项目中使用VideoDecoder类。如果将其设置为VideoPlayer的嵌套类，则无法以优雅的方式进行操作。 而是将其他类放在单独的.h / .cpp文件中，然后可以在VideoPlayer类中使用它们。 VideoPlayer的客户端现在只需要包含声明VideoPlayer的文件，并且仍然不需要知道如何实现它。 决定是否使用嵌套类的一种方法是考虑此类是否起辅助作用或自身的作用。 如果仅出于帮助另一个类的目的而存在，那么我通常将其设置为嵌套类。有很多警告需要注意，其中有些似乎是矛盾的，但所有这些都取决于经验和直觉。 好吧，如果您在Interface类中使用指向工作马类的指针，并且不在接口方法中将它们公开为参数或返回类型，则无需在接口头文件中包含这些工作马的定义(您只需 向前声明它们)。 这样，您的界面用户就无需了解后台中的类。 您绝对不需要为此嵌套类。 实际上，随着项目的发展，单独的类文件实际上将使您的代码更具可读性，并且更易于管理。 如果您需要子类化(例如针对不同的内容/编解码器类型)，它也将在以后为您提供帮助。 这是有关PIMPL模式的更多信息(第3.1.1节)。 我们遇到了一个半旧的Sun C ++编译器以及嵌套类可见性的问题，该嵌套类的行为在标准中有所更改。当然，这并不是没有嵌套类的原因，如果您打算在包括旧编译器在内的许多平台上编译软件，则要注意这一点。 有时，向用户隐藏实现类是合适的-在这种情况下，最好将它们放在foo_internal.h中，而不是放在公共类定义中。这样，您的foo.h读者将看不到您不希望遇到的麻烦，但是您仍然可以针对接口的每个具体实现编写测试。 听起来像是您可以使用策略模式的情况 仅当无法使用可能的外部类的公共接口将其实现为单独的类时，才应使用内部类。内部类会增加类的大小，复杂性和责任感，因此应谨慎使用。 您的编码器/解码器类听起来更适合策略模式 要记住的另一件事是您是否曾设想过工作功能的不同实现(例如解码和编码)。在那种情况下，您肯定会想要一个抽象基类，该基类具有实现这些功能的不同具体类。对于每种类型的实现，嵌套一个单独的子类确实不合适。 避免嵌套类的一个原因是，如果您打算用swig(http://www.swig.org)包装代码，以用于其他语言。 Swig当前在嵌套类方面存在问题，因此与暴露任何嵌套类的库进行接口变得非常麻烦。 |
