我为一个进行电子计算的程序做了Swing'face'。它看起来很棒，但我现在似乎面临着关于如何实现基础计算的一系列令人眼花缭乱的选择。代码变得越来越长，所以我将尝试用一般术语来描述。
我正在研究的面板计算电压降：
我认为这不需要太多的处理能力所以这一切都是在事件调度线程中完成的 - 很好，因为我对线程还不太了解。
我对Java和编程的有限知识有几种不同的方法，我可以想到这个实现，可能还有一些我还不知道。即便是我所知道的那些对我来说仍然有点'朦胧'。
一个。使用在基本上对面板进行任何合法更改时触发的事件侦听器，并将所有变量作为相当多的字符串文字传递给单个逻辑类构造函数，该构造函数解析所有内容并计算结果并具有返回结果的方法。我想它可能有不同的构造函数签名，可以帮助搞清楚该怎么做。每次用户更改面板时，都会创建一个新对象来计算结果。这似乎可能是丑陋而难以使用的。
B中。 “父工厂” - 与（A。）几乎相同，除了将变量作为参数传递给抽象类中的方法，该抽象类确定要执行的操作并创建其子类之一的实例。我认为这至少会使应用程序逻辑的工作变得容易一些。
℃。观察者和观察者？我真的不太了解它是如何工作的。
d。绑定？同样的事情 - 我对此还不太了解。
我还需要在不同的模块中将此类型的计算字符串串联起来。所以我想重用逻辑。
那么 - 我应该跳下哪个兔子洞？我不想把自己编入角落。
答案 0 :(得分：0)
创建单个支持对象，并在更改数据时更新它（侦听事件）。
然后从对象请求更改的计算（或者如果计划在数据更改时允许多个源通知，则使Swing对象侦听'CalculationUpdate'事件。）
每次更改构造一个新对象是完全浪费内存 - 创建然后忽略对象是遇到GC问题的好方法。
答案 1 :(得分：0)
一般来说，已经发现将“用户交互逻辑”（看起来与您已经描述过的内容很好地对应）与“业务逻辑”（看起来就像是您的业务逻辑）分开是有用的。要求）。重要的是让它们彼此分开，你似乎首先通过编写其中一个来完成它。到目前为止，非常好。
我认为您不需要“单个支持对象”作为另一个答案，但我同意您在代码中需要一个“模型”。这可以是一个班级或一些班级;这里重要的是他们实现你的逻辑而不依赖于对用户的呈现或交互。用户可以以任何方式提供数字并将它们传递给模型，它将返回其答案，除模型之外的其他内容将决定如何呈现该答案。
因此，例如，侦听器是swing应用程序的一部分（用户执行某些操作并且侦听器方法触发）：这些是用户交互的一部分。如果您以不同的方式获得问题的输入，那么您将不会拥有这些侦听器，因此它们不属于业务逻辑。
我还认为验证是您的用户交互代码的一部分，因为如果您更改某人输入数字的方式，则验证会更改，而无需了解有关如何使用这些数字的任何信息。因此，在将数字输入模型进行计算之前，我会验证用户的输入;我会记录该代码的输入预计已经过验证，以防后来被没有意识到的人再次使用。
因此，当有人更改某个值时，我希望会有一个侦听器（或某个等效的）被激活，它会验证输入并在有无效数据时为用户生成一条消息;如果输入有效，我希望它调用一个方法来进行计算并返回值，然后更新那个监听器（或者一个SwingWorker线程的监听器，如果你不知道它，请查看）屏幕上的结果（也应仅在用户交互逻辑中完成。
你提到传递字符串;在验证之后，我还会编写用户交互代码，将字符串值转换为应该代表数字的数字。它们是输入字符串的事实是用户如何与代码交互的一部分，而不是业务逻辑的一部分。如果从其他地方获得数字的程序想要使用你的计算模型，如果它必须将其数字转换为字符串，那将是奇怪和愚蠢的，因为你的模型用于在这种情况下从用户获取字符串。
我希望这有用。