我有一个流程，我将自动化为一种GUI逐步向导。从基本的角度来看，这是一套冗长的计算结果，最终会为您提供设计规范。
它分为6个块，每个连续的块依赖于前一个块的结果和输入。我最初考虑过做6个独立的“计算”课程，直到我开始考虑按原样处理值“下线”。
我刚做了一个类似的任务，我在一个已经实现的，非常相似的程序上打了一个GUI，前一个人用不同的类做了它，并且很难跟踪它们并确保它们被交给到正确的班级。
我想把它们全部组合成一个大班。它将有6种方法，我可以从GUI的每个部分收集和提供输入，它将在幕后进行计算，然后在调用所有6个之后，我可以简单地创建一个收集所有重要的输出方法价值并吐出来。
我倾向于一个类，因为它更简单，更像'黑盒子'而且我没有必须使用脏的构造函数，我将之前制作的对象交给最终的类获得所有之前的5个交给它，所以它可以使用这些值。
现在我想起来，这个类可以成为MVC设计的'模型'，并且是一个很好的分离类，Controller和View只能通过7种可见，非常直接的方法访问。
我也认为它会减少内存占用，就像6个单独的类一样，它们需要存在与1个大的相同的持续时间，除了Object的所有内部复制6次。
我相信使用一个类，但我想问这是否是一个可怕的错误，如果它违背所有面向对象的事情，如果我错过了一些明显更好的解决方案。
答案 0 :(得分：3)
将所有步骤放入单个有状态类时要考虑的一些事项：
1）如果你添加确保它始终处于一致状态的代码，它实际上会更简单吗？确保以正确的顺序调用方法？
2）用户可以退后吗？你绝对肯定永远不会要求能够倒退吗？这是否意味着您需要另外6种方法来“反转”步骤并检查对象的状态？ （表面上看，在另一个系统中，如果做得对，你可以“getPrevious”。）
3）谁管理这个对象的生命周期？谁知道你什么时候完成它，它的引用保存在哪里？在另一个系统中，似乎每个屏幕都知道自己的输入和自己的输出。每个屏幕都有一个对象知道整个过程的状态。此外，第一步和最后一步可能具有关于该过程的“特殊知识”，因为它们可能必须包含开始和结束生命周期的代码。
答案 1 :(得分：1)
我怀疑你的问题有一个简单的答案。是将代码拆分为6个类还是合并为1个类将取决于几个标准，包括这6个计算的不同（功能），输入输出值的相关程度等等。
如果计算出一个共同的目标，这6个部分是6个单独的步骤 - 它们只是在一起才真正有意义（其中一个不能从其他地方以合理的意义调用） - 我会选择一流的方法。特别是如果6组不同的计算使用相似/相关的算法和中间值/函数/等。它本质上是MVC世界中的模型。
答案 2 :(得分：0)
只要代码被分解为不同的方法并且你可以保持圈复杂度，我认为没有缺点，如果只使用一个类，有很多潜在的上升空间，特别是在内存占用方面。 / p>
答案 3 :(得分：0)
另一种方法是创建6个类，每个类实现一个公共接口，调用接口Stage。 Stage有一个很好的钩子可以从/向其他Stage提供。这种模块化方法可以使代码对下一个人更具可读性和可更改性。
答案 4 :(得分：0)
我认为在6个单独的文件和类中拆分是没有意义的，我同意。
我的建议是去上课。据我所知，这是Swing编程中一种很常见的做法。优点：
不要错过OOP的优势：
Thread以进行长时间运行的计算）ActionListener（Swing）或SelectionListener（SWT）。由于内部类可以变为私有，因此黑盒模型将完全实现。
答案 5 :(得分：0)
我倾向于一类，因为它更简单，更像'黑盒子'
我不同意。黑盒子背后的想法是外界不需要知道实现细节 - 编程变得更容易，代码更易读，而且当组件更容易被隔离仅由其输入和输出定义。这是界面驱动设计的乐趣。
“一大类”，无论输入和输出定义得多，实际上都是对立到黑盒编程和Java本身。当逻辑子组件应自行管理时，整个模型必须进行微观管理。 （参见@csturtz关于SRP的评论！）。
我也认为它会减少内存占用，就像6个单独的类一样
真的？别担心这个。与Swing或JVM相比，六个模型类的内存占用率可以忽略不计。如果内存实际上是一个严重问题，请将其作为命令行程序。不要为了幻影性能问题而牺牲潜在的OO纯度;构建Java是为了能够编写富有表现力的OO代码，让JRE有效地运行非常。
您似乎正在实施管道设计，其中输入是按步骤处理的。 用课程表示阶段有什么好处？
您可以将管道中的各个阶段提取到接口或抽象类中吗？
我相信使用一个类，但我想问这是否是一个可怕的错误，如果它违背所有面向对象的事情，如果我错过了一些明显更好的解决方案
希望我们清除了这一点。