单个类是否比6个类更简单、更好？

Question

我有一个过程，我正在将其自动化成一种逐步的GUI向导。简而言之，它是一组冗长的计算，最终给出了一个设计的规范。

它被分成6个块，每个连续的块都依赖于前一个块的结果和输入。我最初考虑做6个独立的“计算”类，直到我开始考虑传递值。

我刚刚做了一个类似的任务，我在一个已经实现的，非常相似的程序上做了一个GUI，其中前面的人确实用单独的类做了这件事，跟踪它们并确保它们被交给正确的类是一件相当痛苦的事情。

我在考虑把它们合并成一个大班级。它将有6个方法，我可以从GUI的每个部分收集并提供输入，它将在幕后进行计算，然后在所有6个方法都被调用后，我可以简单地创建一个输出方法，该方法收集所有重要的值并输出它们。

我倾向于一个类，因为它更简单，更像“黑盒”，而且我不需要有脏的构造函数，我把以前创建的对象交给最后一个类，这样它就可以使用值了。

考虑到这一点，这个类可以是MVC设计的“模型”，并且是一个很好的分离类，控制器和视图只能通过7个可见的、非常直接的方法来访问。

我还认为这将减少内存占用，因为有6个独立的类，它们需要与1个大类存在相同的持续时间，除非Object的所有内部都复制了6次。

我相当确信使用one类，但我想问一下，这是不是一个可怕的错误，是否与所有面向对象的东西背道而驰，是否我错过了一些明显更好的解决方案。

Answer 1

在将所有步骤放入单个有状态类时，需要考虑一些事项：

1)如果你添加代码来确保它始终处于一致的状态，会不会更简单？确保以正确的顺序调用这些方法？

2)用户可以倒退吗？你绝对确定这永远不会是一个倒退的要求吗？这是否意味着你需要另外6个方法来“反转”步骤和检查对象的状态？(表面上看，在另一个系统中，如果操作得当，您可以直接"getPrevious“。)

3)该对象的生命周期由谁管理？谁知道什么时候你完成了它，对它的引用保存在哪里？在另一个系统中，似乎每个屏幕都知道自己的输入和输出。有了一个对象，每个屏幕都知道整个进程的状态。另外，第一步和最后一步可能会有关于流程的“特殊知识”，因为它们可能必须包含开始和结束生命周期的代码。

Answer 2

我怀疑你的问题有一个简单的答案。是否将代码拆分为6个类或合并为1个类将取决于几个标准，包括这6个计算(在功能上)有多大不同，输入-输出值有多相关，等等。

假设这6个部分是计算一个共同目标的6个单独步骤-它们只有在一起才真正有意义(这就是说，其中一个不能从其他地方调用，这是合理的)-我会选择1类方法。特别是如果这6组不同的计算使用相似/相关的算法和中间值/函数/等，它本质上就是MVC世界中的模型。

Answer 3

只要代码被分解成不同的方法，并且可以降低圈复杂度，我就看不到任何缺点，如果只使用一个类，特别是在内存占用方面，就有很大的潜力。