oop - 方法 JavaFx TreeItem getRoot() 不可见。它不是 OOP/MVC 的原因是什么？

Question

我需要获取 TreeView 的根项。获得它的明显方法是在 TreeView 上使用 getRoot()。我用的。

我喜欢试验，想知道我是否可以获得相同的根，购买从叶项(TreeItem)爬上树，递归地使用 getParent() 直到结果为 NULL。

它也能正常工作，并且在我的自定义 TreeItem 中，我添加了一个公共(public)方法“getRoot()”来使用它。从而发现该方法确实存在于父TreeItem中，但没有暴露。

我的问题:为什么不公开？关于 OOP/MVC 架构是一种不好的做法吗？

Answer 1

设计的原因由kleopatra的评论总结:

Why would it not be exposed I would pose it the other way round: why should it? It's convenience api at best, easy to implement by clients, not really needed - adding such to a framework/toolkit tends to exploding api/implementation to maintain.

JavaFX 充满了这样的决定故意。很多推理都是基于 AWT/Spring 的经验(好的和坏的)。举几个例子:

• 为了在 UI 线程上指定执行，有一个 runLater API，但没有像 Swing 那样的 invokeAndWait API，尽管框架很容易提供这样的 API 并且已经被请求。

  • 提供 invokeAndWait API 意味着天真的(和有经验的 :-) 开发人员可能会错误地使用它来意外死锁线程。

• 许多类是最终类，不可扩展。

  • 有时开发人员想要扩展类，但不能因为它们是最终类。这意味着他们不能覆盖框架的许多内置测试功能并意外地以这种方式破坏它。相反，他们通常可以使用聚合而不是继承来做他们需要的事情。该框架迫使他们这样做，以保护自己和他们。

• 颜色对象是不可变的。

  • Immutable objects总的来说让东西更容易维护。

• 原生外观不是框架的一部分。

  • 如果需要，您仍然可以创建它们，并且有第 3 方库可以执行此操作，但它不需要位于核心框架中。

• 应用程序编程接口(interface)是单线程的，而不是多线程的。

  • 因为框架的开发人员意识到多线程 UI 框架是一个 failed dream .

其理念是编写代码，使 80% 的用例更容易，而 20% 的用例(通常)成为可能，使用额外的用户或第 3 方代码，同时使用户代码难以意外(或故意)打破框架。您刚刚偶然发现了这一理念的一个应用实例。

您可以使用一大堆流行语来描述采用这种设计方法的原因。它们都不是特定于 OOP 或 MVC 的。基本原则比软件工程存在的时间要长得多，它们只是通向工作和工程的一般方法。如果有兴趣，这里有一些链接:

• 你不会需要它的YAGNI
• 最小可行产品 MVP
• Worse-is-better
• Muntzing
• Feature creep prevention
• 保持简单愚蠢KISS
• Occam's razor