Java架构-常用的类应该在构造函数中传递吗？

Question

我正在用Java设计一个GUI桌面应用程序，它有一个选项卡式界面(就像浏览器中的选项卡)。

MainWindow类创建选项卡式窗口，加载包含每个选项卡代码的其他SWT类，例如Tab1Composite、Tab2Composite。还有一些类处理工具栏菜单的操作，因此依赖于MainWindow来处理本地化(捆绑包)、在选项卡之间切换等事情。

到目前为止，我一直在构造函数中将MainWindow实例传递给其他类。这看起来像是“良好的实践”，但我不禁注意到，如果我只是将所有必要的变量和方法设置为静态的，我的代码将会简单得多。

对我应该使用哪种方法有什么想法吗？

Answer 1

“良好实践”意味着编写可理解、可重用和可扩展的代码。有时快速和肮脏更有意义，但代码的寿命通常比我们预期的更长、更难，即使不是这样，做正确的代码也是很好的实践。

首先，您的主窗口是一个很好的概念。它是许多地方都需要的一组数据。向下传递它的必要性“通过9个中间层”看起来很尴尬，但它清楚地表明，这9个层方法中的每一个都被视为一个内聚的整体，确实需要MainWindow中的信息。使用全局变量将隐藏这一需求，并且是对任何试图维护或增强代码的人开的一种恶作剧。

但是，MainWindow也会创建窗口、选项卡和其他东西。这不需要传递，所以我将创建另一个类来传递信息。这简化了事情。我们未来的维护人员(可能是您)在查看从第4层到第5层的呼叫时，不再需要纠结于为什么第5层需要创建选项卡。创建几个这样的类可能是有意义的，以最大限度地减少不需要的信息量。

下一步需要注意的是，实际使用此信息的对象并不知道或不太关心MainWindow。随着时间的推移，它们可能会在完全不同的程序中使用，或者在这个程序中以不同的方式使用。他们获得的信息可能不是来自MainWindow。他们想要的不是类实例，而是接口实例。切换到接口，您的代码将变得更简单、更灵活。

最好不要对这一切过于得意忘形。我的意思不是说你现在应该做很多工作。相反，如果你的项目继续进展顺利，你想要记住你的方向。

(请注意，公共字段和静态方法不能很好地与Java接口配合使用！避免使用它们。)

Answer 2

如果您不打算创建MainWindow类的任何实例，那么我将使共享成员成为静态成员。但是，不能从静态上下文引用非静态成员，因此如果在现在的静态方法中使用其他非静态方法和变量，它们也必须是静态的。

基本上，您将为它们分配一个固定的内存位置，因此只是静态地引用它们并不是坏事。然而，我总是设法避免让事情变得静态。如果你发现你必须使很多成员都是静态的，重新考虑你程序的结构。( of members )

尽量避免将任何东西设为静态的(常量除外)。将GUI从“工作”中分离出来是正确的做法。将你的程序看作一棵树，并将其组织起来，这样创建的对象就不需要调用树中它上面的东西了。当然，这并不总是可行的，但它使测试、扩展和调试(在大多数情况下)变得更容易。

Answer 3

这真的取决于你想要如何制作你的程序。我想说的是，如果您计划创建多个MainWindow，那么将其设置为静态可能不是一个好主意。否则，我不能完全确定将MainWindow设为静态的缺点是什么。(除了只能引用MainWindow中的静态变量和方法之外。)

另一方面，您可以在MainWindow类中使用一个接口来封装选项卡，以允许多个MainWindow类而不会造成混淆。在我看来，如果标签页严重依赖于MainWindow，这似乎是最好的。(我相信这与mort的答案类似。)

对我来说，“良好的实践”应该意味着“良好的编程”，所以如果您的代码似乎更适合使用静态引用，那么就使用它。只需确保保留一个后备计划，以防出现问题。

再说一次，Java不是我的首选语言，所以我可能有一些概念混乱。