Java面向对象策略
Java OOP strategy
我有一个名为可视化数据结构的项目。我有这样的 OOP 设计。
Class VisualDataStructures extends JFrame
Class ControlPanel extends JPanel
Class CodePanel extends JPanel
Class VisualDataStructures有主。此 class 具有 Class ControlPanel 和 CodePanel 的实例。
Class ControlPanel 在 JMenuBar.
中有 JMenuItem 命名为 "Load"
Class CodePanel 有一个 JTextArea。
问题：
我需要在 class ControlPanel 中为名为 "load" 的 JMenuItem 创建一个动作监听器。当点击加载时，用户会进入文件的目录，然后文件会被加载并显示在CodePanel.
的JTextArea处
我是否需要将从 VisualDataStructures 实例化的对象 CodePanel 传递给 ControlPanel 以便我使用该对象然后修改 JTextArea 的值？
有人知道更好的方法吗？谢谢。
在没有看到实际代码的情况下回答这个问题有点困难，但我仍然会尝试。也许如果您可以通过 Github、Bitbucket、作为 Gist 或在 Pastebin 中以某种方式共享您的代码，我可以给出更好的答案。然后在 CodeReview stackexchange 而不是 Whosebug 上执行此操作可能会更好。
总的来说，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。它们提供了非常有趣的功能。以正确的方式使用，它们可以大大简化代码。
我有一个名为可视化数据结构的项目。我有这样的 OOP 设计。
Class VisualDataStructures extends JFrame
Class ControlPanel extends JPanel
Class CodePanel extends JPanel
Class VisualDataStructures有主。此 class 具有 Class ControlPanel 和 CodePanel 的实例。
Class ControlPanel 在 JMenuBar.
JMenuItem 命名为 "Load"
Class CodePanel 有一个 JTextArea。
问题：
我需要在 class ControlPanel 中为名为 "load" 的 JMenuItem 创建一个动作监听器。当点击加载时，用户会进入文件的目录，然后文件会被加载并显示在CodePanel.
JTextArea处
我是否需要将从 VisualDataStructures 实例化的对象 CodePanel 传递给 ControlPanel 以便我使用该对象然后修改 JTextArea 的值？
有人知道更好的方法吗？谢谢。
在没有看到实际代码的情况下回答这个问题有点困难，但我仍然会尝试。也许如果您可以通过 Github、Bitbucket、作为 Gist 或在 Pastebin 中以某种方式共享您的代码，我可以给出更好的答案。然后在 CodeReview stackexchange 而不是 Whosebug 上执行此操作可能会更好。
总的来说，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。它们提供了非常有趣的功能。以正确的方式使用，它们可以大大简化代码。