我正在处理与电影播放相关的应用，目前我遇到了一些设计问题。
正如您所料，我有一个电影类，其中包含文件路径，文件大小等属性。 电影类对电影内部结构一无所知，也没有直接解码电影文件。
为了达到这个目的，我有另一个大类：解码器。 这个类知道所有电影内部，如持续时间，帧速率等。 它还提供从文件中检索视频或音频数据的方法。 将解码器分解成更小的块是没有多大意义的，因为解码器使用第三方库并且需要传递大量的C指针。为了简化内存管理等，我宁愿避免使用它。
电影中包含一个具有明确定义界面的解码器，因为解码器本身是使用我的电影类中的策略模式实现的。
Movie ----------------> Decoder (implements interface)
| |
v v
File related variables Movie internals
我想知道这种设计在信息隐藏和SRP方面是否合适。 所有外部类都知道电影具有带有一堆属性的解码器。 让他们只知道有电影会不会更好？ 但是电影类会变得庞大，并且会有很多存根方法只能访问解码器的属性。
任何建议都将受到赞赏。
编辑：
我深入了解了Facade模式（灵感来自@ Erik的回答），看起来就像是完美匹配。我可以进一步细分电影课程，但外面的世界＆＃34;不应该知道细节以避免复杂性。但是，这将产生一个包含许多方法的Facade类。
因此，它看起来像是一个来自外部的巨大阶级，而在内部看时，它很好地分成了逻辑砖块。 你认为那样好吗？
答案 0 :(得分：1)
不是将所有代码都拉入新类，而是创建一个本身不包含逻辑的新类，而只是包装一个Movie并公开一大堆方法，每个方法都调用Movie和Decoder上的必要方法。
这基本上是Facade Pattern的实现：
https://en.wikipedia.org/wiki/Facade_pattern
它的优点是外面的课程不知道电影是如何工作的，而不是“这是我们可以要求的所有这些属性的课程”，而在内部则不会有大型课程。
答案 1 :(得分：1)
Movie是一个包含Movie属性的数据对象，而Decoder是一个处理元素，似乎提供了API来对Movie对象执行各种操作。
您可以修改Decoder以接受Movie对象并执行这些操作。 Movie不需要引用Decoder对象。解码器更像是Movie对象的Visitor。如果无法修改解码器类，则可以创建一个Proxy类，该类提供这些采用Movie对象的API，并使用Decoder对象的适当属性调用Movie类中的方法