什麼時候考慮使用靜態

這些各種說法，基本上都是正確的。但是，其中絕大多數是講了「靜態」和「例項」的區別，以及靜態方法的特徵。

很少有說到何時或是為什麼要使用靜態的。

靜態包括靜態類和靜態成員（靜態方法和靜態屬性），既然搜尋出來的這些說的都是靜態成員（基本上說的都是靜態方法），那麼我也就先僅對靜態方法談一談自己的看法。

上中學數學，尤其是平面幾何的時候，老師經常講「定義」與「性質」的區別。「性質」只是它表現出來的特徵而已，而「定義」才是真正的決定性的東西。

我覺得，靜態方法的「定義」當然是 static 關鍵字了。沒有用到this指標，這一點才是靜態方法的首要「性質」（本質特徵）。像什麼【共通】【全域性】【單例模式】呀，那都是它的應用場景，或是說使用靜態方法來達到的目的。

那麼說到「何時該使用靜態方法」其實是困擾很多程式設計師的苦惱問題。不明白這一點，也從乙個側面反映出對oo思想的理解不夠，就很可能通過濫用靜態方法已達到在物件導向的語言中繼續進行面向過程的程式設計，這是很可怕的。

其實，方法是否涉及具體類的例項，或者簡單的說是否涉及「資料」（如果使用就要用到this指標）是決定是否使用靜態方法的根部要因。然而，判斷是否涉及到「資料」也是要看當前設計思路的。有時候不夠oo的設計，可能會將本該設計到資料的例項方法，從「資料相關」變成「資料無關」。（與oo不同，面向過程的程式設計就是將方法與資料分開）在這樣的設計思路下，你會發現怎麼什麼動作都是與資料無關的呢？恩，這就該開始濫用靜態方法了。

本想舉乙個好一點的例子，但是時間匆忙，就簡短說一下 log 吧。有人認為寫日誌是乙個工具在幹活，應該是 log.debug(...);

有人認為，日誌記錄器是個「小精靈」應該有血有肉， log logger = new log(); logger.debug(...);

可能你會認為，這要取決於log類以及debug方法的複雜程度；

也許你會認為，這要看log類中是否有「資料」，比如，輸出level；

也許還有其他理由。

而我覺得可以說是仁者見仁智者見智，也可以看做是不同的程式設計風格，也可以... 總之，需要細細體會了。

追加乙個稍好一些的例子：檢查 textbox 是否輸入了資料，如果沒有，則依據某乙個id，從配置檔案中讀取一句話（錯誤資訊），然後彈出，並將此 textbox 的底色置成紅色，再將焦點放到上面去。

如果你不希望這一系列的操作（大概6-7行**）每次都要寫一遍，你就會設法把它提煉為「共通」。

方法一：（靜態）

1
public
class
checker  2  
12}  
13}  
1415     checker.checkempty(textbox1);

方法二：（例項）

1
public
class
mytextbox : textbox  2  
12}  
13}  
1415
16     mytextbox textbox1 = new
mytextbox();  
17........   
18    textbox1.checkempty();

因為swing使用的很少，所以就用winform的控制項來舉例子了，所以**是c#的，其實沒有關係，所有oo語言在這一點上都是一樣的。

如果你不覺得【擴充套件】sdk的控制項有多麼恐怖，或者應為其他原因已經對其擴充套件了，那麼我更推薦使用例項方法（方法二）。理由嗎，對控制項的檢查本來就是和控制項自身（text屬性）息息相關的，是活生生的。

（這裡不討論讀配置檔案、messagebox 等操作是否違背開閉原則）

什麼時候考慮使用靜態

什麼時候使用靜態？

什麼時候我們考慮使用指令碼

什麼時候考慮使用分治演算法

什麼時候考慮使用靜態

什麼時候使用靜態？

什麼時候我們考慮使用指令碼

什麼時候考慮使用分治演算法

相關推薦