一个问题是,所有的规则都在他们一些回旋余地,你必须使用自己的最佳判断。
例如,你现在所描述的应用程序在我看来如此简单,我可能会做它在一个类中,也许一对夫妇嵌套,也许匿名类的。无论如何,我可以做一个合适的案例,将整个事件整合到一个源文件中,声称多个源文件实际上会增加整个事物的复杂性。
但是如果你的GUI有一些不同的控件,或许每个控制不同的行为,这将成为一次分裂的功能了这样你就不会用面条代码大碗结束了。
Java GUI库尝试从模型中自然分离(视图+控制器)。我们鼓励您在一个模块(=文件)中定义和显示GUI,但要将数据模型和功能放在另一个模块中。对于复杂的GUI,可能还有多个由代码组成的GUI实现模块。
让事情“干净”的一种方法是在“层”中工作,其中每个层只“知道”它需要知道的东西。具体而言,GUI层需要知道其基础模型–表的存在和列表以及不需要连接到TableModel
和ListModel
等等。尽管如此,它并不需要了解这些模型的细节,所以它可以通过界面简单地引用这些模型。
另一方面,模型层不需要关于GUI的知识。知道的越少越好,这在理论上可以让您无需触摸模型即可交换GUI。
我的模型还可以包含ActionListener
以回应由例如在GUI中按下按钮。
当然,对模型的操作和更改通常会导致GUI的更改。如果模型层不知道GUI,如何将这些更改传递给GUI?你可以在这里使用绑定的bean属性。这里有一个简短的教程:http://www.javalobby.org/java/forums/t19476.html。所以你有相同的结构:变化发生在你的模型中,它们通过模型中的属性更改支持传递给bean,GUI可以将侦听器附加到这些属性以找出发生了变化的东西。
无论您是在模型代码中执行实际的有效操作(例如写入文件,转换数据,无论是否),还是将“处理”代码拆分为另一个模块都取决于您,并且将依赖于您的混乱程度模型已经是。如果有一小部分领域和方法在那里感到孤独,你可能决定把它们混合在一起,但是当它开始变得凌乱时,你会想要将你的处理代码重构到它自己的模块中。处理听起来像是不想知道其他模块的那种模块;你最终可能只是从模型级调用它的方法。
我已经描述了我做GUI开发的基本风格。当然还有其他建议,你可能会根据自己的经验开发自己的风格。这只是为了给你一个想法和一个可能的起点。
感谢您的示例和书籍链接。这正是我需要让我走上正确的轨道。 – MESLewis 2010-01-06 15:55:02
我祝你一切顺利。每个人都必须从某处开始......真正理解如何构建程序需要一段时间。当你开始的时候,你总是可以放弃它,只需将它们拼凑在一起即可实现SOMETHING的运作。你可能会自己看到它有什么问题。 :) – 2010-01-06 15:57:09