做出改變如此容易,導致程式設計過程中疲於應付變化。多年來的事實已經證明,凍結變化是不可能也是不切實際的想法,因而,必須尋找能夠應付改變的設計原則。

然而,看過這麼多的原則,真的能讓程式碼更完美嗎?還是只想來首五人電子樂隊(Five Man Electric Band)的〈Signs〉(https://goo.gl/dXHdAz)吶喊一下呢?

物件導向設計五原則

在《jQuery in action》的〈The jQuery plugin authoring guidelines〉中,以五人電子樂隊的〈Signs〉歌詞寫道:「標示!告示!到處都有這些提示!大煞風景,傷了我的心。這樣作!別那樣作!你是看不懂提示嗎?」作為開場,用以反映現今軟體設計原則如此之多,令人生厭。

到底是為了什麼,我們需要這麼多原則?稍微注重設計的程式人,談到原則最不陌生的,大概就屬Robert C. Martin(Bob大叔)提出的硬(SOLID)道理,SOLID分別是SRP、OCP、LSP、ISP、DIP的首字縮寫詞,而後面這五個又分別是Single Responsibility Principle、Open-Closed Principle、Liskov Substitution Principle、Interface Segregation Principle、Dependency Inversion Principle,程式人真的很愛縮略詞!

對於這五個原則,網路上搜尋「SOLID 設計」,就會有看不完的資料,每篇看起來都很有道理。也有人說到,程式寫太少,看過的程式太少,就無法體會這些原則的重要,而稍微寫過些程式,對程式有些痛苦經驗的,反而會對這些原則抱以崇拜,至於程式設計經驗豐富的人,則又認為這幾個原則不過就只是常識,就像覺得設計模式,不過就是取了些名字的東西罷了。

要是遵守原則就能避免混亂,就好了,不過仔細看看,這些原則像是在許願,試問,哪個程式會不希望相依物件改變時,不影響自身?誰又會希望某個介面改變,自己也被迫修改?更換另一個次型態物件時,當然會希望原程式行為沒有變化,新增功能時,能不改既有程式,也是每個人都想要的結果,萬不得已必須修改程式時,最好只改一個地方就好。

既然如此,我們的需求「改變」中,會有這五種造成程式「改變」的原因嗎?若沒有改變的原因,抱著五大原則檢討程式碼能否應付改變,感覺就挺空洞的!

簡單設計四原則

空洞!大概就是死抱著SOLID原則,試圖完美遵守的感受,問題就在於,不會有完美的設計。

如果對於SOLID原則生厭,或許可以看看Kent Beck在eXtreme Programming提倡的〈Xp Simplicity Rules〉(http://goo.gl/mM4R7J),其中對於簡單的程式碼列出了四個目標:「通過所有測試」、「能表達出我們想表達的所有意圖」、「每件事只說一遍而且只有一遍」、「沒有多餘的部份」。與SOLID著重在面對「改變」要有足夠的彈性相比,Kent Beck的簡單設計四原則,側重在完成既有的目標,並擁有未來面臨修改時的「本錢」。

這大概就跟面對感冒時,真正重要的是訴諸身體的抵抗力,是一樣的道理,若感冒病毒真的入侵了,那麼重點就在於身體要有本錢抵抗病毒。既然需求變化免不了,在針對需求做出程式碼上的變化時,就要有本錢迎接變化,要有能測試的程式碼來告訴我們,既有的程式功能被破壞掉了什麼;既然要改變程式,那麼就要能看懂既有程式的意圖,才知道如何做出修改;程式碼不重複,遇到要修改時,才不用到處搜尋、取代、新增程式。

至於「沒有多餘的部份」,則是〈You Arent Gonna Need It〉(http://goo.gl/Jwzw24)中,寫到的「在真的有需要時實作,而不是預期會有需求而實作」。

而且,其中說到,這除了節省時間之外,也可以避免「猜測」這件事,污染了程式碼,這大概跟別吃多餘的營養品來做「加強身體抵抗力」的這件事,是類似的道理吧!

說是簡單設計四原則,要完成這些目標,可真的不簡單,測試本身是門學問,程式碼要怎麼寫才能被測試,測試程式本身該怎麼寫,採用哪種測試方法論等,都得有十足的學習與經驗,如何撰寫出清楚、可讀的程式碼也是件難事,為此,或許你得研讀Bob大叔的《Clean Code》,或相關的書籍,想要程式碼不重複,視情況也有多種不同的實作方式,有時重複也沒那麼簡單可以看出來,有時狀態或行為上的不重複,也是得考量在內。

重構的三次法則

在簡單設計四原則中的「每件事只說一遍而且只有一遍」,有著另一個比較多人熟悉的名詞DRY,也就是Don't Repeat Yourself,或者另一個相對的名詞WET,也就是Write Everything Twice。

DRY一詞,目前認為最初出現在《The Pragmatic Programmer》中〈The Evils of Duplication〉,當中也將重複大致區分為四個類型:被迫(Imposed)、不經意(Inadvertent)、沒耐心(Impatient)與開發者之間(Interdeveloper)的重複。

被迫的重複是指那些因為專案環境的關係,導致某些資訊不得不重複地出現在選用的標準、技術或工具之中;不經意的重複,書中則舉了Line物件具有start、end、length屬性,其中length就屬於不經意的重複,因為length可藉由start、end求得;沒耐心的重複,大家較為熟悉,往往是因為沒時間、沒耐心或想抄捷徑,而用了複製、貼上、修改的做法;開發者間的重複,則是最複雜、最難以察處理的,不慎寫出具有相同功能,甚至是具有相同Bug的的程式碼等,都是可能的情況。

實際上,重複的類似也不僅止於此,重點在於面對重複,並不是立即奉行DRY這麼簡單,去除重複有時需要的成本極高。當去除重複後,發現被提取出來的部份,也只被用上過這麼一次,因此,有人寧可採用笨一點的方式,也就是採用KISS(Keep It Simple, Stupid)原則,認為某些時候去除重複是YANGI(You Arent Gonna Need It)!

這麼說來,DRY與KISS有時是有衝突的。在《Refactoring》書中〈When Should You Refactor?〉談到Don Roberts提出的三次法則(The Rule of Three):「第一次做某件事時只管去做;第二次做類似的事會產生反感,但無論如何還是做了;第三次再做類似的事,你就應該重構。」

在Derick Bailey的〈Abstraction: The Rule Of Three〉(https://goo.gl/B0WEhW)中,也提到三次法則有助於模式的察覺,像是數學上,1, 2, _, _, _, _很難判定數列後續數字為何,然而1, 2, 3, _, _, _的話,就可能推斷出後續是4, 5, 6的模式。

你的程式碼STUPID嗎?

我們看過幾個原則?SOLID、DRY、WET、KISS、YANGI、The Rule of Three,你還有沒有聽過Law of Demeter?在《Clean Code》中的說明是「只跟朋友說話,不跟陌生人聊天」,並舉了Apache框架中的程式碼ctxt.getOptions().getScratchDir().getAbsolutePath(),這種取得物件細節後又取得下個物件細節的做法,就違反了Law of Demeter,這會使得目前物件依賴於其他物件的內部結構。

那麼,這麼多原則的提出到底是為了什麼?在〈Don't be STUPID: GRASP SOLID!〉(http://goo.gl/iXJw6V)提出了另一個角度的看法「抱歉,但你的程式碼就是STUPID!」STUPID代表了Singleton、Tightcoupling、Untestability、Premature Optimization、Indescriptive Naming 、Duplication,對了,GRASP也是一堆原則的縮略詞!

當然,蠢程式並不只有這些問題,作者也承認STUPID是特意搞出來的名詞,不過,或許能解釋這麼多原則,不是讓程式碼更完美,而只是希望我們能看出自己的程式碼中犯了哪些蠢事,才會導致後續缺少彈性、無法測試、難以閱讀、到處充滿重複的程式碼,如果看著這些原則時,能夠嘖嘖稱是,那大概是過去曾經犯過不少蠢事了吧

作者簡介


Advertisement

更多 iThome相關內容