我需要獲取 TreeView 的根專案。獲得它的顯而易見的方法是在 TreeView 上使用 getRoot()。我使用的。
我喜歡實驗，并且想知道我是否可以獲得相同的根，購買從葉項（TreeItem）爬上樹，使用遞回 getParent() 直到結果為 NULL。
它也能正常作業，并且在我的自定義 TreeItem 中，我添加了一個公共方法“getRoot()”來使用它。從而發現這個方法在父TreeItem中已經存在，但是沒有暴露出來。
我的問題：為什么它不會被暴露？關于 OOP/MVC 架構是一種不好的做法嗎？
uj5u.com熱心網友回復：
kleopatra的評論總結了設計的原因：
為什么它不會被暴露，我會反過來擺姿勢：為什么要暴露？它充其量是方便的 api，易于由客戶實作，并不是真正需要的 - 將這樣的添加到框架/工具包中往往會導致 api/實作爆炸式的維護。
JavaFX 充滿了這樣的決定是故意的。很多推理都是基于 AWT/Spring 的經驗（好的和壞的）。只是一些例子：
為了指定在 UI 執行緒上執行，有一個 runLater API，但沒有像 Swing 這樣的 invokeAndWait API，盡管框架很容易提供這樣的 API 并且已經請求了它。
- 提供 invokeAndWait API 意味著天真的（和有經驗的 :-）開發人員可能會錯誤地使用它來意外死鎖執行緒。
許多類是最終的，不可擴展。
- 有時開發人員想要擴展類，但不能因為它們是最終的。這意味著他們不能覆寫框架的許多內置測驗功能，并以這種方式意外破壞它。相反，他們通常可以使用聚合而不是繼承來做他們需要的事情。該框架迫使他們這樣做，以保護自己和他們。
顏色物件是不可變的。
- 不可變物件通常使東西更易于維護。
本機外觀和感覺不是框架的一部分。
- 如果需要，您仍然可以創建它們，并且有 3rd 方庫可以做到這一點，但它不需要在核心框架中。
應用程式編程介面是單執行緒的，而不是多執行緒的。
- 因為框架的開發者意識到多執行緒 UI 框架是一個失敗的夢想。
其理念是撰寫代碼以使 80% 的用例更容易并使 20% 的用例（通常）成為可能，使用額外的用戶或第 3 方代碼，同時使用戶代碼難以意外（或故意）破壞框架. 您剛剛偶然發現了這種哲學應用的一個實體。
您可以使用大量標語來描述這種設計方法的原因。它們都不是 OOP 或 MVC 特定的。基本原則比軟體工程存在的時間要長得多，它們只是一般的作業和工程方法。如果有興趣，這里有一些鏈接：
- 你不需要它YAGNI
- 最小可行產品MVP
- 越差越好
- 蒙青
- 特征蠕變預防
- 保持簡單愚蠢的KISS
- 奧卡姆剃刀
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/352981.html
上一篇：如何從底部垂直列印？