亂談程式設計的小惡魔 - 靜態函式


程式設計的小惡魔,你的名字是 「靜態函式」

程式設計中幾乎都會用到 Function Call,我想這應該是結構化程式設計重要的元素之一。伴隨著物件導向程式設計的普及與氾濫,程式設計師對於 Function Call 不陌生,一天總要寫個幾百次才過癮。為什麼說"物件導向程式設計"氾濫呢?因為現在假設哪種語言沒有物件的概念,常常會覺得這個語言遜掉了....... -_-

其實 Function Call 不需要介紹也沒什麼特別的,特別的是它的寫法與實作千變萬化。今天我想談的是靜態函式/類別函式 (Static Method),為什麼需要謹慎思考靜態函式呢?因為我們常常覺得靜態函式非常好用與便利,久而久之就會移遺忘靜態函式對系統造成的影響,或者根本沒想過呼叫靜態函式對系統有何影響?好吧.......讓我們來看看靜態函式

Method 就是 Method,是不是靜態有差嗎?沒錯,除了靜態變數要注意多時序 (MultiThread) 的問題外,似乎絕大多數的靜態函式在使用上與實體化 (Instance) 的物件方法用起來效果差不多,甚至更方便且程式寫起來更短,這些優點真是太吸引我們了,我們應該鼓吹大量使用靜態函式才對....... -_- 我只是開開玩笑!!

但是靜態函式有一個缺點,就是靜態函式在同一個 Runtime (同一個Runtime可以想像為同一個程序) 中所使用的記憶體位置是相同的,也就是所謂的獨生子 (Singleton)。通常如此之目的是希望系統能確保 Class 在 Runtime 中只有一個唯一的實例 (Instance),常常用在兩個實例間的溝通。假設想讓寫出來的程式同時擁有可實例化與保留靜態的獨生性 (Singleton) 與互通性,最常見到的 Desgin Pattern 就是 getInstance(),如下所示(Java example):

 有了上述的程式,我們就可以透過 Singleton.getInstance().run() 來調用函式,也可以 new Singleton() 後再調用實例化的函式,哇.......真方便,我相信這樣的寫法已經普遍出現在各種系統與 API 中。然而我以前撰寫的程式也常有這樣的影子出現,表面上似乎解決的問題,實際上只是把靜態函式變得能夠不靜態了

拉回正題,讓我們思考調用靜態函式對系統的影響吧。說穿了,就是依賴關係,當你直接使用類別中的靜態方法時,你的程式碼已經跟這個類別產生依賴關係。複雜的依賴關係對於系統的維護與彈性是有阻礙的。假設靜態函式修改了,那麼你就必須把所有調用靜態函式的程式碼重新 Review 一次,這樣可是很累的工作。

有了不少教訓以後,我慢慢的少寫靜態函式了,大部分盡可能設計出需要實體化的類別,未來可透過上層框架的管理來調用函式,大幅提高程式重用性。除了僅處理計算或轉換的功能才會寫成靜態函式(類別函式)之外,現在確實不太設計靜態函式了。

此外在許多著名的 IoC / DI 的實作框架中,更是不推崇靜態類別函式的呼叫,如此將會提降低系統的耦合度。假設不這麼做,久而久之將會造成系統的負擔與累積包袱,演變成必須砍掉重練的情況。然而在早期沒有完整軟體測試的系統中,系統重構的風險是很高的,系統重構又是另一門學問了,有機會再與大家分享。

物件導向優點多於缺點是絕對的,善用 Design Pattern 避免缺點寄居在我們所設計的系統中,那麼物件導向將會是很優異的程式設計風格。

Facebook 留言

廣告

樂樂童鞋