这里的一个问题是，所有规则都有一些余地，你必须使用自己最好的判断。
例如，您现在描述的应用程序在我看来如此简单，我可能会在一个类中执行它，可能有几个嵌套的，也许是匿名类。无论如何，我可以将整个事物整合到一个源文件中，声称多个源文件实际上会增加整个事物的复杂性。
但是如果您的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开发的基本风格。当然还有其他建议，您可能会根据自己的经验开发自己的风格。这只是为了给你一个想法和一个可能的起点。
