java - 用于复杂类交互的Java Swing设计模式

Question

我正在开发将具有多个子系统的java swing应用程序。出于所有目的和目的，让我们假设我正在制作一个具有随机附加功能的Internet聊天程序。该功能将是一个日程安排程序，您可以在其中设置时间并获得提醒，还可以通知朋友列表中的每个人您都得到了提醒。

将此功能分为三类是有意义的：GUI，ChatManager和Scheduler。这些类将执行以下操作：

GUI-定义所有摆动组件和事件
ChatManager-创建聊天连接，发送和接收消息，管理好友列表
计划程序-监视系统时间，发送通知，存储文件以记住会话之间的事件

为了使程序正常运行，每个类都必须能够与其他两个类进行通信。 GUI需要告诉ChatManager何时发送消息，并告诉Scheduler何时开始监视。当收到消息时，ChatManager需要在GUI上显示消息，最后，调度程序需要在完成时通知GUI，并将状态更新或任何内容发送给ChatManager。

当然，这里描述的类都非常简单，让它们直接相互通信可能不是一个坏主意。但是，出于这个问题的考虑，让我们假设交互要复杂得多。

例如，假设我们可以向调度程序注册特定事件，而不是特定时间。发送消息时，我去了将其发送给用户，将其存储在日志文件中，创建了一个事件对象，并将其传递给调度程序，并处理了过程中可能引发的任何异常。

当通信变得如此复杂时，如果可以在许多不同的地方与这些类进行通信，则很难维护您的代码。例如，如果要重构ChatManager，则可能还需要对GUI和Scheduler进行重大更改（如果引入新内容，还需要进行其他更改）。这使代码难以维护，并使我们睡眠不足的程序员在进行更改时更有可能引入错误。

最初似乎最有意义的解决方案是使用调解器设计模式。这个想法是，这三个主要类中没有一个直接知道彼此，而是每个都知道一个中介者类。中介类又定义了处理这三个类之间通信的方法。因此，例如，GUI将调用中介者类中的sendMessage（）方法，而中介者将处理一切需要发生的事情。最终，这使三个主要类别脱钩，对其中一个类别的任何更改都可能只会导致调解者的更改。

但是，这带来了两个主要问题，最终导致我来这里寻求反馈。它们如下：

问题


许多任务将需要更新GUI，但是介体不知道这些组件。 -假设用户启动该程序并输入其用户名/密码，然后单击“登录”以登录到聊天服务器。登录时，您想通过在登录屏幕上显示文本来报告登录过程，例如“正在连接...”，“正在登录...”或“错误”。如果在Mediator类中定义了登录方法，则显示这些通知的唯一方法是在GUI类中创建一个公共方法来更新正确的JLabel。最终，GUI类将需要大量方法来更新其组件，例如显示来自特定用户的消息，在用户登录/注销时更新您的朋友列表等。此外，您还必须期望这些GUI更新可以随时随机发生。这样可以吗？
Swing事件调度线程。您通常会从组件ActionListeners调用中介方法，该方法在EDT上执行。但是，您不想在EDT上发送消息或读取/写入文件，否则您的GUI将变得无响应。因此，在介体对象中提供一个SingleThreadExecutor是一个好主意，而介体对象中的每个方法都定义了一个新的可运行对象，可以提交给执行者线程？同样，必须在EDT上进行GUI组件的更新，但是Executor线程将调用方法来更新GUI组件。因此，GUI类中的每个公共方法都必须将自己提交给EDT以执行。那有必要吗？


对我来说，在GUI类中有一个方法来更新以某种方式与外部进行通信的每个组件似乎是很多工作，而这些方法中的每一个都具有额外的监听功能，即检查它是否在EDT上，并将其自身添加到EDT中。 EDT否则。此外，Mediator类中的每个公共方法都必须执行类似的操作，将Runnable代码添加到Mediator线程中或启动一个工作线程。

总体而言，使用Mediator模式维护应用程序似乎要比不使用Mediator模式维护应用程序花费更多的工作。因此，在此示例中，您有什么不同（如果有）？

Answer 1

您的GUI类将使用多种方法来保持最新状态，这很好。如果让您担心，则始终可以选择将GUI分解为子GUI，每个子GUI具有不同的功能或少量相关功能。方法的数量显然不会改变，但会更加有条理，连贯和分离。
我建议您尝试其他解决方案，而不是在GUI中创建每种方法，然后使用SwingUtilities.invokeLater将该更新放入EDT。对于我的个人项目，我使用Swing Application Framework（JSR296），它具有一些方便的Task类用于启动后台作业，然后成功方法自动在EDT线程上。如果您不能使用它，则应尝试为后台作业创建自己的类似框架。