---編輯,因爲很長的回答可以不適合評論---
我會從c2.com模式和反模式的討論論壇,在那裏人們可以潛入錯綜複雜引用面向對象的思維方式,研究不同方法的優缺點。
這是一個根本的違反封裝給功能更多 訪問私人狀態超出他們的要求。 作爲類成員保留的實用方法通常被授予比它們要求更多的訪問權限,這使得難以識別和執行設計不變量。 如果某個方法的功能可以用類的 公共接口表示,那麼將其寫入非成員函數會增加總體封裝。
一個包含所有靜態方法的類最終必須自行處理傳遞給它的類中的所有數據和項目。這導致了一些問題。
- 它顛倒了封裝,因爲行爲永遠變爲類的外部。例如,下面例子中的「doSomething」不屬於任何類實例。反轉封裝==更像結構的類,缺乏解決問題所需的關鍵行爲。
- 它使單元測試變得複雜。我可以嘗試鞭打一個快速的例子,但this covers it far better than I would be able to do so quickly。
- 它使您的代碼難以維護,易於預見將需要維護。是否認爲你可能需要第二份文件?玩得開心(一種錯誤注入技術),或將你的東西轉換爲實例(通過代碼進行有趣的搜索),這樣你就可以擁有一個基類和子類來區別差異。從實例開始,您只需標記實例類abstract,創建兩個子類文件,並將一個方法移動到「was default」子類中,爲另一個子類編寫方法。沒有通過代碼庫狩獵==贏。
- 所有靜態類都很難卸載。如果不使用它們,沒有減少內存的可能性,沒有一些非常奇特的類加載。
- 所有靜態類都很難提高性能。無法爲每個線程或每個並行任務創建類。不保證在方法調用之間可以阻止其他線程調用方法。通過實例,您可以創建線程專用實例。
該列表繼續,但如果您覺得您的情況值得特別考慮,那麼請使用靜態方法。
---原帖如下 -
具有所有靜態成員和方法的類很有問題。爲什麼不創建一個實例,就像這樣
public class FileMethods {
private final Document doc;
public FileMethods() {
doc = DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
}
public void doSomething() {
doc.checkSomething();
doc.doSomething();
doc.doSomethingElse();
}
}
它就在那裏。您現在可以同時處理兩個文檔。您還可以獲得在單元測試框架中測試FileMethods類的能力(沒有一些真正落後的代碼)。
只要例外。
try {
doc = ...;
} catch (SomeCompilerException e) {
e.printStackTrace();
}
是一個好的開始。更好的是,如果您無法處理該代碼塊中的例外...
public FileMethods() throws SomeCompilerException {
doc = DocumentBuilderFactory.newInstance().newDocumentBuilder().newDocument();
}
並在代碼塊中處理它,使其有意義。
try {
FileMethods methods = new FileMethods();
methods.doSomething();
} catch (SomeCompilerException e) {
System.out.println("Not possible to make a document right now due to " + e);
}
這就是我的想法。只是想知道是否有辦法讓它自動運行。感謝你的回答! – JaySee
@JaySee那麼你總是可以禁用檢查的異常。 – Antimony
@JaySee如果我的回答對你有幫助,那麼請點擊我答案左邊的勾號來接受它。接受答案有助於其他人面臨同樣的問題/困惑。 –