英國前首相本杰明·迪斯雷利（Benjamin Disraeli）曾有一個古老的說法，說謊言分為三種：“謊言，該死的謊言和統計數據”。 這里的暗示是統計數據很容易彌補它們是不可靠的。 但是，統計學在經驗科學中得到了廣泛的應用，因此它們肯定具有某些優點嗎？ 實際上，它們有很多優點。 但僅當正確使用它們時。 問題是它們很容易被濫用。 當被濫用時，會出現錯誤信息，進而弊大于利。

在軟件工程領域中，與這種敘述有很強的相似之處。 面向對象的語言引入了繼承的概念，這是促進代碼重用的聰明的主意。 但是，繼承（如果被濫用）很容易導致復雜的層次結構，并且很難更改對象。 濫用繼承會造成嚴重破壞，并且由于使用繼承（在Java中）只需要能夠拼寫“擴展”一詞，因此如果您不知道自己在做什么，就很容易就可以破壞這種破壞。 類似的故事可以通過多態和設計模式來講述。 我們都知道有人陷入地獄而致力于使用一種模式，而不是他們試圖解決的問題，而更多地思考該模式。 即使他們了解網橋和適配器之間的區別，架構的某些部分還是很有可能被過度設計。 也許值得記住的是，GOF設計模式中的每一個都已經在JDK中了 ，因此，如果您確實希望在您的體系結構中使用它，則不必看起來太遠-否則僅在有意義時使用它。

這種“強大的使用，破壞性的濫用”反模式在Java系統中無處不在。 Servlet過濾器是用于處理請求和響應的非常方便的功能，但這僅是它們要做的。 語言中沒有什么可以阻止開發人員將過濾器視為經典對象，而是向過濾器添加公共API和業務邏輯。 當然，決不要以這種方式使用過濾器，并且在出現故障時不可避免地會發生這種情況。 但是關鍵是，開發人員可以輕松地利用如此強大的功能，濫用它并破壞體系結構。 在Aspects中，甚至在異常（我們都已經看到拋出異常的情況下，僅返回布爾值會更有意義）以及其他許多功能中，“強大的使用，破壞性的濫用”的發生非常容易。

當容易犯錯誤時，不可避免地會發生錯誤。 Java編譯器不會說-“等等，您真的了解這個概念嗎？” 和代碼樣式工具還不夠復雜，無法發現對高級概念的濫用。 此外，沒有公司有時間讓最高級的人來檢查每一行代碼。 即使是最高級的工程師也會犯錯。

現在，這里寫的很多東西都是顯而易見的，并且已經被很好地記錄在案。 強大的功能通常必須很好地理解才能正確使用。 我認為值得一問的問題是，在以Java為中心的體系結構中是否有任何功能不那么容易濫用的強大功能或工程概念？ 我建議至少有一個，即：封裝。 首先，讓我們考慮一下封裝是否不存在。 一切都將是公共的或全局的（如Javascript）。 一旦訪問范圍縮小，就會發生封裝，這通常是一件好事。 通過封裝行為是否會使架構更糟？ 好吧，很難想到一個可能的情況。 如果將方法設為私有，則可能難以進行單元測試。 但這是真的嗎？ 對調用它的方法進行單元測試總是很容易的，它將在同一類和邏輯單元中。

這里有個教訓要學習。 一旦設計了其他用途的東西，無論它是體系結構中的核心組件，實用程序庫類還是REST API，您都將要向世人介紹一下，請問自己：

人們濫用它有多容易？ 它處于繼承的風險級別還是封裝的安全級別？

濫用的后果是什么？

您如何做才能最大程度地減少濫用及其后果？

旨在增加“強大的使用”并最大程度地減少“破壞性濫用”！

參考： 濫用的思考： 都柏林技術博客博客上的JCG合作伙伴 Alex Staveley的“強大使用，破壞濫用” 。

相關文章 ：

• Java 7功能概述
• Java SE 7、8、9 –推進Java
• 回收對象以提高性能
• Java Secret：加載和卸載靜態字段
• Java最佳實踐系列
• 軟件設計法則

翻譯自: https://www.javacodegeeks.com/2011/12/musing-on-mis-usings-powerful-use.html

總結

以上是生活随笔為你收集整理的沉思滥用：“强力使用，破坏滥用”的全部內容，希望文章能夠幫你解決所遇到的問題。

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