2014-10-28 49 views
1

应如何管理监听器等?我发现只有一个按钮的例子等Java Swing GUI用户操作处理

我能想到的下列选项:

  1. 每个额外的类 - 看起来不正确,特别是当项目 可以动态创建
  2. 对于每个组类(如Form1中, 窗口2,controlButtonsOnLeft,controButtonsOnRight,MAINMENU, userMenu的,...),其中我会检查哪个按钮/组件引起这样 (经由的getSource例如方法)
  3. 一些超级(大小)控制米勒, 将接受所有用户操作每个
  4. 新的匿名类, 它将调用控制器的方法与指定 细节(可能枚举)

而另一个问题参数:我发现了很多的例子MVC,我想知道什么更好(或常用)的应用程序。由1人开发(应用程序不会很大)?

A.查看器设置听众控制器(A1-3)

B.控制器调用观看者的方法,它接受作为听者参数(方法addLoginSubmitListener,addControlBoldButtonListener等)

所有的以上是能够实现到目前为止,我会选择B4。 含义在控制我会做这样的事情:

​​

这(在代码一个地方1个逻辑部分)结合可读代码,那并不产生任何不必要的冗余码,那并不需要任何难溶动态支票,是容易可重复使用等等。 您能否确认/评论此解决方案?

+0

当为侦听器使用匿名实现时,以后无法在处理对象时将其移除,最终(以及您*将*具有这些情况)会导致内存泄漏。 – alterfox 2014-10-28 22:36:06

+0

@alterfox:感谢您指点。 – Anonym 2014-10-28 22:52:01

+0

@alterfox:这不是由GC处理的吗?监听器的列表是这种匿名监听器的唯一参考,在组件处置期间它将被清空,对吗?或者我也许会误解。在这种情况下,我将为此创建一个类并为构造函数添加一个参数,这将决定哪个方法将处理它。 [也许有更好的解决方案,这是第一个跨过我的脑海] – Anonym 2014-10-28 23:02:08

回答

1

说实话这个问题归结到了一些问题......

  • 你想重用?
  • 你想配置吗?
  • 它们是自包含的吗?也就是说,是否有其他人倾听组件或需要在将来修改监听器的结果动作?

我个人倾向于自我控制。给定动作/任务的单个监听器。这使得我需要时更容易管理和更改。

如果我不需要可重用性(监听者)或可配置性,那么匿名内部类通常是首选。它隐藏了功能,并且不会使用小的一次性使用类来混淆源代码。你应该小心它可以使源代码难以阅读。这当然假定这个任务是专门构建的(它是一个单独的案例)。通常,在这些情况下,我更愿意从实际执行工作的侦听器中调用其他方法,这为班级提供了一定的灵活性和可扩展性。通常情况下,你会发现自己希望修改组件的行为,以便找到隐藏在匿名或私有内部类中的行为。

如果您想要重用性和/或可配置性 - 也就是说,侦听器执行的任务可以在整个程序中重复执行,或者通过库随时间重复执行,那么您需要为任务提供专用类。再次,我倾向于自给自足的解决方案,因此任何一个听众只做一项工作,更容易更改单个听众,然后通过if-else陈述的复合列表进行挖掘:P

这也可以是一系列的abstract监听器,可以像操作建立功能,例如从表中删除的行...

你可以考虑类似的Action API(见How to Use Actions有详细介绍),这是自包含的工作单位,但其中还携带配置信息。它们被设计成与按钮一起工作,如JButton s和JMenuItem s,但也可以与键绑定一起使用,使它们非常通用......

您问题的第二部分(关于MVC)取决于。我更愿意尽可能将UI相关的功能保留在视图中并且离开控制器。我宁愿为控制器/视图交互提供我自己的专用监听器,而不是让控制器直接将监听器设置为组件,而是为控制器通知控制器可能想知道的视图更改,反之亦然。

想想这样。您可能有一个登录控制器和视图,但控制器只关心从视图中获取凭据并在视图发出请求时对其进行身份验证,而不关心如何从视图角度进行请求。这允许你为不同的情况设计不同的视图,但只要你维持视图和控制器之间的契约,它就不会有什么区别......但那只是我自己。