Question

我想创建一款既可以在本地也可以在线工作的游戏。

我的第一个想法是创建一个接口，该接口具有GUI所需的所有方法，用于业务逻辑，然后具有网络实现和本地实现。

这适用于请求 - 响应消息。但是，服务器发送的消息呢，我必须更新一些GUI组件（即JLabel）？

我的第一个解决方案是实现侦听器，其中实现中的每个更改都将触发一个事件。 GUI将适当地注册和更改它的组件。但是，在业务逻辑中调用触发事件看起来有点不对。

我是否走在正确的轨道上？因为我想我不是。有什么建议吗？

谢谢。

注意：客户端是一个简单的Java Swing GUI。

Answer 1

您所描述的内容将有助于保持模型独立于演示问题，这是一件好事。这也可以帮助您在模型的设计，开发和维护过程中，因为您可以在模型中的某些更改应该触发特定事件的基础上编写单元测试，而不必担心屏幕上的内容。

当然，它可以让您自由地为不同的环境设计不同的GUI设计。

关键是事件应该是关于模型状态的变化，而不是关于表示级别的预期动作/表示。让表示层处理是否/如何响应模型事件。

Answer 2

我承认我做网络开发，所以我对Swing没有多少经验。

但我一直认为我接近它的方式是将应用程序分解为包/视图，/ model和/ controller。这些关系是单向的：/ controller会知道/ model和/ view，但是它们都不会从/ controller或彼此导入任何类。

/ view图层组件永远不会是JFrame;它们总是JPanel或其他合适的容器，可以根据需要组合成JFrame。每个都有对Listener接口的引用，在构造函数中初始化，并且会遵循这些参数进行事件处理：

public class ExamplePanel extends JPanel implements ActionListener
{
    private JButton button;
    private ActionListener buttonListener;

    public ExamplePanel(ActionListener buttonListener)
    {    
        this.button = new JButton("Do Something");
        this.buttonListener = buttonListener;
        this.button.addListener(this.buttonListener);
    }

    public void actionPerformed(ActionEvent e)
    {
        this.buttonListener.actionPerformed(e);
    }
}

这种安排适用于依赖注入，因为现在控制器可以选择使用该Listener接口的本地或远程实现，以一种不影响客户端的方式改变行为。

我承认我从未完全遵循它。

春天的人有一个丰富的Swing客户端模块，但似乎已经失宠了。看起来他们已经确定BlazeDS方向对于富客户来说是更好的选择。但也许你可以从他们的方法中收集一些设计思路。

将业务与Presentation Logic分开的最佳方式？

2 个答案: