1

我正在开发与电影播放相关的应用程序，目前遇到了一些设计问题。

如您所料，我有一个包含文件路径、文件大小等属性的电影类。电影类对电影的内部结构一无所知，也不直接解码电影文件。

为了实现这一点，我还有另一个大类：解码器。此类了解所有电影内部信息，例如持续时间、帧速率等。它还提供从文件中检索视频或音频数据的方法。将解码器分成更小的块没有多大意义，因为解码器使用第三方库，并且需要传递大量 C 指针。为了简化内存管理等，我宁愿避免这种情况。

电影拥有一个具有明确定义接口的解码器，因为解码器本身是使用我的电影类中的策略模式实现的。

                  Movie      ---------------->     Decoder (implements interface)
                    |                                  |
                    v                                  v
           File related variables                 Movie internals

我想知道这种设计在信息隐藏和 SRP 方面是否良好。所有外部类都知道一部电影有一个带有一堆属性的解码器。让他们只知道有电影不是更好吗？但是电影类会变得非常庞大，并且会有很多只访问解码器属性的存根方法。

任何意见，将不胜感激。

编辑：

我深入研究了 Facade 模式（受@Erik 的回答启发），它看起来像这里的完美匹配。我可以进一步细分 Movie 类，但“外部世界”不需要了解细节以避免复杂性。但是，这将产生一个包含许多方法的 Facade 类。

因此，从外部看它是一个巨大的类，而从内部看它被很好地分成逻辑砖块。那你觉得还可以吗？

4

2 回答 2

1

与其将所有代码拉入一个新类，不如创建一个新类，它本身不包含任何逻辑，只是简单地包装一个 Movie 并公开大量方法，每个方法调用 Movie 和 Decoder 上的必要方法。

这基本上是外观模式的实现：

https://en.wikipedia.org/wiki/Facade_pattern

它的优点是，除了“这是具有我们可以要求的所有这些属性的此类”之外，外部类不了解电影的工作原理，而在内部，您最终不会得到庞大的类。

于 2014-12-30T11:00:43.353 回答
1

Movie是一个包含电影属性的数据对象，而解码器是一个处理元素，它似乎提供了 API 来对电影对象执行各种操作。

您可以修改您的Decoder以接受Movie对象并执行这些操作。Movie不需要引用Decoder对象。解码器更像是一个Visitor电影对象。如果无法修改解码器类，则可以创建一个代理类，该类提供这些 API，这些 API 获取Movie对象并调用Decoder具有对象适当属性的类中的方法Movie。

于 2014-12-30T11:04:30.463 回答