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

我正在研究用于视频回放和录制的类的集合。我有一个类似公共接口的主类,使用 play()stop()pause()record()等...然后我有工作马上做视频解码和视频编码的类。

我刚刚学习了C ++中嵌套类的存在,并且我很想知道程序员如何使用它们。我有点警惕,并不确定它的好处/缺点,但它们似乎(根据我正在阅读的书)将用于像我这样的情况。

本书表明,在像我这样的场景中,一个好的解决方案是将接口类嵌套到接口类中,所以没有单独的客户端不想使用的类的文件,并且避免了任何可能的命名冲突?我不知道这些理由。嵌套类对我来说是一个新概念。只是想看看程序员对这个问题的看法。

0
额外 编辑
意见: 1

9 答案

我会有点不情愿在这里使用嵌套类。如果您为“多媒体驱动程序”创建抽象基类以处理后端工作(主力),并为前端工作创建单独的类,那该怎么办?前端类可以采用指向/实现的驱动程序类的引用(适用于适当的介质类型和情况),并在主马结构上执行抽象操作。

我的理念是继续努力,让客户能够以优美的方式使用这两种结构,只是假设他们会一起使用。

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

0
额外

sounds like a case where you could use the strategy pattern

0
额外

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

如果它仅仅是为了帮助另一个类而存在,那么我通常会把它作为一个嵌套类。这里有一些注意事项,其中一些似乎是矛盾的,但一切都归结为经验和直觉。

0
额外

那么,如果您在Interface类中使用指向您的主力类的指针,并且不要在接口方法中将它们作为参数或返回类型公开,则不需要在接口头文件中包含这些工作马的定义(您只需转发宣布他们)。这样,你的界面的用户将不需要知道背景中的类。

你绝对不需要为此嵌套类。实际上,随着项目的增长,单独的类文件实际上会使您的代码更易读,更易于管理。如果您需要继承子类(比如说不同的内容/编解码器类型),它也将在以后帮助您。

以下是有关 PIMPL模式的更多信息(第3.1.1节)。

0
额外

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

Your encoder/decoder class sounds like it better fits the Strategy Pattern

0
额外

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

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

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

0
额外

有时将用户隐藏实现类是合适的 - 在这些情况下,最好将它们放在foo_internal.h中,而不要放在公共类定义中。这样,你的foo.h的读者就不会看到你不喜欢的东西,但是你仍然可以针对你的界面的每个具体实现编写测试。

0
额外

我们遇到了一个半旧的Sun C ++编译器以及嵌入类的可见性,这些行为在标准中发生了变化。当然,如果你打算在包括旧编译器在内的许多平台上编译你的软件,那么这不是不要做你的嵌套类的理由。

0
额外

另一件需要记住的是,你是否设想过你的工作功能的不同实现(例如解码和编码)。在这种情况下,你肯定会想要一个具有不同具体类的抽象基类来实现这些功能。为每种类型的实现嵌套一个单独的子类是不合适的。

0
额外