在这种情况下我应该使用嵌套类吗？
我正在研究用于视频播放和录制的类集合。 我有一个主类，其行为类似于公共接口，具有诸如 play()、stop()、pause()、等方法>record() 等等...然后我有主力类来执行视频解码和视频编码。
我刚刚了解到 C++ 中嵌套类的存在，我很想知道程序员如何看待使用它们。 我有点谨慎，不太确定其优点/缺点是什么，但它们似乎（根据我正在阅读的书）可用于像我这样的情况。
这本书建议，在像我这样的场景中，一个好的解决方案是将主力类嵌套在接口类中，这样客户端不打算使用的类就没有单独的文件，并避免任何可能的命名冲突。 我不知道这些理由。 嵌套类对我来说是一个新概念。 只是想看看程序员如何看待这个问题。
I am working on a collection of classes used for video playback and recording. I have one main class which acts like the public interface, with methods like play(), stop(), pause(), record() etc... Then I have workhorse classes that do the video decoding and video encoding.
I just learned about the existence of nested classes in C++, and I'm curious to know what programmers think about using them. I am a little wary and not really sure what the benefits/drawbacks are, but they seem (according to the book I'm reading) to be used in cases such as mine.
The book suggests that in a scenario like mine, a good solution would be to nest the workhorse classes inside the interface class, so there are no separate files for classes the client is not meant to use and to avoid any possible naming conflicts. I don't know about these justifications. Nested classes are a new concept to me. Just want to see what programmers think about the issue.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
另一件需要记住的事情是您是否曾经设想过工作功能的不同实现（例如解码和编码）。 在这种情况下，您肯定需要一个具有实现功能的不同具体类的抽象基类。 为每种类型的实现嵌套一个单独的子类实际上并不合适。
Another thing to keep in mind is whether you ever envision different implementations of your work functions (such as decoding and encoding). In that case, you would definitely want an abstract base class with different concrete classes which implement the functions. It would not really be appropriate to nest a separate subclass for each type of implementation.
避免嵌套类的原因之一是，如果您打算用 swig 包装代码 (http://www.swig.org< /a>) 用于其他语言。 Swig 目前在嵌套类方面存在问题，因此与公开任何嵌套类的库进行交互变得非常痛苦。
One reason to avoid nested classes is if you ever intend to wrap the code with swig (http://www.swig.org) for use with other languages. Swig currently has problems with nested classes, so interfacing with libraries that expose any nested classes becomes a real pain.
仅当无法使用可能的外部类的公共接口将内部类实现为单独的类时，才应使用内部类。 内部类增加了类的大小、复杂性和责任，因此应谨慎使用它们。
您的编码器/解码器类听起来更适合 策略模式
You should use an inner class only when you cannot implement it as a separate class using the would-be outer class' public interface. Inner classes increase the size, complexity, and responsibility of a class so they should be used sparingly.
Your encoder/decoder class sounds like it better fits the Strategy Pattern
好吧，如果您在 Interface 类中使用指向主力类的指针，并且不在接口方法中将它们公开为参数或返回类型，则不需要在接口头文件中包含这些主力类的定义（您只需改为向前声明它们）。 这样，界面的用户将不需要了解后台的类。
您绝对不需要为此嵌套类。 事实上，随着项目的增长，单独的类文件实际上将使您的代码更具可读性并且更易于管理。 如果您需要子类化（例如不同的内容/编解码器类型），它也会在以后为您提供帮助。
以下是有关 PIMPL 模式（第 3.1.1 节）的更多信息。
Well, if you use pointers to your workhorse classes in your Interface class and don't expose them as parameters or return types in your interface methods, you will not need to include the definitions for those work horses in your interface header file (you just forward declare them instead). That way, users of your interface will not need to know about the classes in the background.
You definitely don't need to nest classes for this. In fact, separate class files will actually make your code a lot more readable and easier to manage as your project grows. it will also help you later on if you need to subclass (say for different content/codec types).
Here's more information on the PIMPL pattern (section 3.1.1).
我们遇到了半旧的 Sun C++ 编译器和嵌套类的可见性问题，其行为在标准中发生了变化。 当然，这并不是不执行嵌套类的原因，只是如果您计划在包括旧编译器在内的许多平台上编译软件，则需要注意这一点。
We hit an issue with a semi-old Sun C++ compiler and visibility of nested classes which behavior changed in the standard. This is not a reason to not do your nested class, of course, just something to be aware of if you plan on compiling your software on lots of platforms including old compilers.
有时，对用户隐藏实现类是适当的——在这些情况下，最好将它们放在 foo_internal.h 中，而不是放在公共类定义中。 这样，您的 foo.h 的读者将不会看到您希望他们不被困扰的内容，但您仍然可以针对接口的每个具体实现编写测试。
Sometimes it's appropriate to hide the implementation classes from the user -- in these cases it's better to put them in an foo_internal.h than inside the public class definition. That way, readers of your foo.h will not see what you'd prefer they not be troubled with, but you can still write tests against each of the concrete implementations of your interface.
听起来你可以使用策略模式
sounds like a case where you could use the strategy pattern
决定是否使用嵌套类的一种方法是考虑该类是否扮演支持角色或它自己的角色。
如果它的存在只是为了帮助另一个类，那么我通常将其设为嵌套类。 对此有很多警告，其中一些似乎是矛盾的，但这一切都取决于经验和直觉。
One way of deciding whether or not to use nested classes is to think whether or not this class plays a supporting role or it's own part.
If it exists solely for the purpose of helping another class then I generally make it a nested class. There are a whole load of caveats to that, some of which seem contradictory but it all comes down to experience and gut-feeling.
您可以使用嵌套类来创建实现主类所需的（小）辅助类。 或者例如，定义一个接口（具有抽象方法的类）。
在这种情况下，嵌套类的主要缺点是这使得重用它们变得更加困难。 也许您想在另一个项目中使用 VideoDecoder 类。 如果将其设为 VideoPlayer 的嵌套类，则无法以优雅的方式执行此操作。
相反，请将其他类放在单独的 .h/.cpp 文件中，然后您可以在 VideoPlayer 类中使用它们。 VideoPlayer 的客户端现在只需要包含声明 VideoPlayer 的文件，并且仍然不需要知道您是如何实现它的。
You would use a nested class to create a (small) helper class that's required to implement the main class. Or for example, to define an interface (a class with abstract methods).
In this case, the main disadvantage of nested classes is that this makes it harder to re-use them. Perhaps you'd like to use your VideoDecoder class in another project. If you make it a nested class of VideoPlayer, you can't do this in an elegant way.
Instead, put the other classes in separate .h/.cpp files, which you can then use in your VideoPlayer class. The client of VideoPlayer now only needs to include the file that declares VideoPlayer, and still doesn't need to know about how you implemented it.
我有点不愿意在这里使用嵌套类。 如果您为“多媒体驱动程序”创建一个抽象基类来处理后端内容（主力），并为前端工作创建一个单独的类，会怎么样？ 前端类可以采用指向已实现的驱动程序类的指针/引用（针对适当的媒体类型和情况）并对主力结构执行抽象操作。
我的理念是继续以一种完美的方式让客户可以访问这两种结构，前提是它们将同时使用。
我会在 Qt 中引用类似 QTextDocument 的内容。 您为裸机数据处理提供直接接口，但将权限传递给 QTextEdit 等对象来执行操作。
I would be a bit reluctant to use nested classes here. What if you created an abstract base class for a "multimedia driver" to handle the back-end stuff (workhorse), and a separate class for the front-end work? The front-end class could take a pointer/reference to an implemented driver class (for the appropriate media type and situation) and perform the abstract operations on the workhorse structure.
My philosophy would be to go ahead and make both structures accessible to the client in a polished way, just under the assumption they would be used in tandem.
I would reference something like a QTextDocument in Qt. You provide a direct interface to the bare metal data handling, but pass the authority along to an object like a QTextEdit to do the manipulation.