jtable隱藏全部

在較早的文章中 ，我寫了以下幾句話： 在面向對象的代碼庫中，該工具包應盡可能離散。 您使用開發套件的次數越多，您的代碼實際面向對象的次數就越少，或者您的抽象并不是最好的。 。

我認為有必要詳細說明這一點，因為它很強，而且該文章并沒有充分說明這一點。

湯姆和杰瑞–兩位小印第安人，威廉·漢納和約瑟夫·巴貝拉

我承認，這個想法很簡單，盡管可能是理想主義的：查看代碼庫時，我應該能夠通過查看對象的實例化，觀察它們如何組成和修飾每個實例來理解應用程序的功能和業務邏輯。其他。 就像我在另一篇文章中所說的那樣，您應該將業務邏輯隱藏在清晰的視野中 。

基本上，這意味著我不需要為了了解您的程序應該在何時執行什么操作而查看任何算法，Collection處理，任何類型的數據操作或對實用程序方法的調用。 所有這些細節都應該分解為最小的部分，并隱藏在接口實現的背后。 換句話說，您的代碼應盡可能具有聲明性-請記住， 命名是最重要的方面之一。

不用說，這種方法需要大量的設計工作，尤其是在架構師方面：我相信架構師應該做的第一件事就是設計對象的接口 。 理想情況下，他/她應該交付一個僅包含Java接口的框架項目，并附帶詳細的JavaDocs，這些JavaDocs解釋最終對象應如何協同工作，也許還有一些其他實現想法。 然后，提供實現并將所有內容放在一起就像是一個難題，這是開發人員的工作–我什至不會提及測試應該完全覆蓋每個對象。

缺點當然是，錯誤可能會花費更多的精力，可能花費在重新設計內容上。 另一方面，這樣的應用程序將小得多，并且永遠不會變成龐然大物。 只需簡單地知道什么地方適合，就不必問自己“我應該在哪里放置這種方法？” 或“我們是否應該在此服務中再添加一種方法？ 它已經很大了。” 新的東西應該無縫地或完全不適合，在這種情況下，您可以考慮編寫一個新的應用程序（是的，為什么不呢？）。

此外，添加功能應該意味著只需實現一個接口，并且只有在該接口之后，您才可以考慮使用開發工具–也許還沒有，這取決于抽象的深度。 反過來，刪除功能或邏輯應該意味著僅從某個位置刪除對象的實例化或修飾，并且要注意，這不應在項目中留下任何未調用的方法。 最壞的情況是，您應該有一個未使用的類 ！

綜上所述，以上所有內容聽起來可能很奇怪，但您應該這樣想：您始終確保從業務邏輯中抽象出View和Persistence層； 為什么不更進一步，將JDK隱藏起來呢？ 我知道，您永遠不必更改它，但是很明顯，在沒有完全抽象和封裝的情況下使用它會將代碼變成半OOP事物，這種事物只會繼續增長并變形。 最后，是的，讓我們假設JDK（實際上更準確地說是Java SE）將消失：您構造的對象和測試將保持相同，您只需要使用手頭的新工具包提供新的實現即可； 這就是OOP的全部意義！

翻譯自: https://www.javacodegeeks.com/2019/06/hide-all.html

jtable隱藏全部

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的jtable隐藏全部_全部隐藏！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。