Oop 为了简单起见，大型类可以吗？

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

正如您所期望的，我有一个movie类，它具有文件路径、文件大小等属性。 movie类不知道有关电影内部的任何信息，也不直接解码电影文件

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

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

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

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

如有任何建议，将不胜感激

---

编辑：

我更深入地研究了门面图案（灵感来自@Erik的回答），它看起来是这里的完美搭配。我可以进一步细分电影类，但“外部世界”不需要知道细节，以避免复杂性。然而，这将产生一个包含许多方法的Facade类

因此，从外部看，它似乎是一个巨大的类，而从内部看，它被很好地划分为逻辑块。

---

您认为这样可以吗？

您可以创建一个本身不包含逻辑的新类，而只是围绕一部电影并公开一大组方法，每个方法都调用电影和解码器上的必要方法，而不是将所有代码拉入一个新类中

这基本上是Facade模式的一个实现：

---

它的优点是，外部类不知道电影是如何工作的，除了“这是一个拥有我们可以要求的所有属性的类”，而在内部，你不会得到巨大的类。

movie

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

---

您可以修改

解码器

以接受

电影

对象并执行这些操作<代码>电影不需要引用

解码器

对象。解码器更像是一个电影对象。如果无法修改解码器类，则可以创建一个代理类，该类提供这些API，这些API接受

电影

对象，并使用

电影

对象的适当属性调用

解码器

类中的方法。

通常大型类是不好的。它本身就破坏了封装。我很清楚这一点，但您的评论无助于解决问题。我很清楚：）。我把你的问题投了赞成票。我认为添加大量包装器代码而不是添加逻辑确实是有动机的。顺便说一句，问题是大型类是否合适。我说不。即使那个巨大的类被分解成包含的类，我考虑过这一点，我认为这是行不通的。电影和解码器都只使用一个文件路径初始化。解码器不需要电影。它只需要文件路径。此外，我有一个UI元素，显示有关电影的所有相关信息，这些信息来自电影和解码器对象。