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

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

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

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

我的问题：为什么不暴露？关于 OOP/MVC 架构是一种不好的做法吗？

标签： oopjavafxmodel-view-controllerarchitecture

kleopatra 的评论总结了设计的原因：

为什么不暴露我会反过来摆出它：为什么要暴露？它充其量只是方便的 api，易于由客户实现，并不是真正需要的——将这样的添加到框架/工具包中往往会导致 api/实现爆炸以进行维护。

JavaFX 充满了故意这样的决定。很多推理都是基于 AWT/Spring 的经验（好的和坏的）。只是一些例子：

为了在 UI 线程上指定执行，有一个 runLater API，但没有像 Swing 这样的 invokeAndWait API，尽管框架很容易提供这样的 API 并且已经被请求。
- 提供一个 invokeAndWait API 意味着天真的（和有经验的 :-）开发人员可能会错误地使用它来意外死锁线程。
许多类是最终的，不可扩展。
- 有时开发人员想要扩展类，但不能，因为它们是最终的。这意味着他们不能覆盖框架的许多内置测试功能并意外破坏它。相反，他们通常可以使用聚合而不是继承来做他们需要的事情。该框架迫使他们这样做，以保护自己和他们。
颜色对象是不可变的。
- 不可变对象通常使东西更容易维护。
本机外观不是框架的一部分。
- 如果需要，您仍然可以创建它们，并且有 3rd 方库可以这样做，但它不需要在核心框架中。
应用程序编程接口是单线程的而不是多线程的。
- 因为框架的开发者意识到多线程 UI 框架是一个失败的梦想。

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

您可以使用大量流行语来描述这种设计方法的原因。它们都不是 OOP 或 MVC 特定的。基本原则的存在时间远远超过软件工程，它们只是一般的工作和工程方法。如果有兴趣，这里有一些链接：