Java OOP 策略

Question

我有一个名为 Visual Data Structures 的项目。我有这样的 OOP 设计。

Class VisualDataStructures extends JFrame
Class ControlPanel extends JPanel
Class CodePanel extends JPanel

Class VisualDataStructures 是主要的。此类具有 Class ControlPanel 和 CodePanel 的实例。

Class ControlPanel 在JMenuBar 中有名为“Load”的JMenuItem。

Class CodePanel 有一个JTextArea。

问题：
我需要在类ControlPanel 中有一个名为“load”的JMenuItem 的actionlistener。点击加载后，用户会进入文件所在目录，此时文件会被加载并显示在CodePanel的JTextArea处。

我是否需要将从 VisualDataStructures 实例化的对象 CodePanel 传递给 ControlPanel 以便我使用该对象，然后修改 JTextArea 的值？

有人知道更好的方法吗？谢谢。

Answer 1

在没有看到实际代码的情况下回答这个问题有点困难，但我仍然会尝试。也许如果您可以通过 Github、Bitbucket、作为 Gist 或 Pastebin 以某种方式共享您的代码，我可以给出更好的答案。那么在 CodeReview stackexchange 而不是 StackOverflow 上执行此操作也可能会更好。

总的来说，我觉得有这么多来自 GUI 父类的extends 有点可疑。 通过扩展使用可能有点反模式。一开始它可能会导致在小型应用程序中出现看似简单的代码，但从长远来看，它往往会混淆源代码，因为它鼓励业务逻辑和 UI 的混合。扩展是OOP的核心是一种误解。它不是。多态抽象以解耦和反转关键依赖关系，这是 OOP 的核心。扩展只是一个不错且方便的好东西，而且它被过度使用了。

说到这个，你可能听说过MVC - 模型视图控制器。这是 UI 将事物分开的典型模式。

您不希望对load 操作做出反应的ActionListener 直接知道CodePanel，因为这样的依赖关系太具体了。您希望在两者之间有一个抽象，例如接口，并引用该接口而不是 CodePanel。

谈到ActionListener 和类似接口，如果您还没有升级到Java 8，您可能有兴趣升级。像 ActionListener 这样只有一个抽象方法的接口是隐式函数式接口，这意味着您可以使用 lambda 或方法引用。

总的来说，我认为始终牢记以下问题会大有帮助：如果我用其他工具包替换 UI 工具包会怎样？ 即使它不是用例，也永远不会发生这种情况时，您为回答该问题所做的关注点的解耦和分离会导致更模块化、更好的设计，这些设计更易于理解和维护。最后，如果我将 UI 工具包替换为不同的工具包会怎样？这个问题会导致设计遵循更多SOLID 原则。

在 Swing 中处理ActionListener 时，您可能需要查看interface Action 和abstract class AbstractAction。它们提供了非常有趣的功能。用对了，可以大大简化代码。