DRY
DRY(Don't Repeat Yourself )原則
凡是寫過一些代碼的程序猿都能夠意識到應該避免重復的代碼和邏輯。我們通過提取方法,提取抽象類等等措施來達到這一目的。我們總能時不時的聽到類似這樣的話:”把這些公用的類放到shared項目去,別的項目還要使用。。。“,什么算是公用(重復)的代碼?是不是公用(重復)的代碼就要放到一個叫shared的地方?
為什么說重復的代碼和邏輯會帶來問題呢?
你從一個類中復制了一段代碼到另一個類中,但是這段代碼足夠的穩定,百年不變,這樣的重復會帶來問題嗎?
也許不會。
如果這段代碼需要時不時的修改,那么你就要花時間去修改所有包含這段邏輯的代碼,這樣無形中增加了維護成本和發生bug的幾率。這時候就要著手消除和抽取重復的代碼。
對于消除重復的代碼有一個三次法則(rule of three):
1.第一次先寫了一段代碼。
2.第二次在另一個地方寫了一段相同的代碼,你已經有消除和提取重復代碼的沖動了。
3.再次在另一個地方寫了同樣的代碼,你已忍無可忍,現在可以考慮提取和消除重復代碼了。
這一法則也適應于對重構時機的把握,過早的重構可能會引入新的問題,三次法則給了你一個重構依據。當然,隨著你經驗的增長,你可能在第二階段已經能非常有信心的預料到問題所在。
什么樣的代碼算是重復的?
DRY is about Knowledge一文中給了這樣一個實例:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 |
|
這兩段代碼中都有一個相同的方法addProduct,這兩段代碼算是重復的嗎?他們違反DRY原則嗎?
作為一個領域驅動的實踐者,我們可以從業務的角度來分析這一代碼,第一段代碼似乎是一個用戶在購物,但是我們最多允許用戶購買三件商品。在第二段代碼的場景中,我們想要給所有用戶提供相同的機會并限制用戶最大購買數量。
這一分析說明了這兩段代碼所描述的領域(Domain)、業務(Business)、知識(Knowledge)、邊界(Boundary)、職責(Resposibility)不同,這兩段代碼之所以相同完全屬于巧合。對這樣的代碼進行提取和消除重復是錯誤的。
我之前待的team維護了一個北美的項目,如果讓我指出這一項目最大的設計問題,就是將一些本不應該提取的代碼(各種Model、數據訪問)抽取到了一個叫做Shared的工程中,這一舉動導致開發人員在后期不敢再修改Shared工程中的任何代碼,以至于開發人員寧可重新添加一個方法也不敢修改之前的代碼。
DRY看似初級人員都要掌握的能力,如果使用不當會造成非常嚴重的后果,正是因為我維護了這樣的項目才有感而發,希望大家引以為戒,當然大家若是有不同的看法可以一起討論。
總結
- 上一篇: 神舟笔记本电脑U盘启动装系统BIOS设置
- 下一篇: JAVA实现可设置背景的MDI窗口