223
技術社區[雲棲]
代碼的抽象三原則
原文:https://www.ruanyifeng.com/blog/2013/01/abstraction_principles.html
作者: 阮一峰
日期: 2013年1月31日
軟件開發是"抽象化"原則(Abstraction)的一種體現。
所謂"抽象化",就是指從具體問題中,提取出具有共性的模式,再使用通用的解決方法加以處理。
開發軟件的時候,一方麵,我們總是希望使用別人已經寫好的代碼,另一方麵,又希望自己寫的代碼盡可能重用,以求減少工作量。要做到這兩個目標,這需要"抽象化"。
最近,我讀到美國程序員Derick Bailey的一篇文章,談到"抽象化"應該遵循的三個原則,覺得很有啟發。
一、DRY原則
DRY是 Don't repeat yourself 的縮寫,意思是"不要重複自己"。
軟件工程名著《The Pragmatic Programmer》首先提出了這個原則。它的涵義是,係統的每一個功能都應該有唯一的實現。也就是說,如果多次遇到同樣的問題,就應該抽象出一個共同的解決方法,不要重複開發同樣的功能。
這個原則有時也稱為"一次且僅一次"原則(Once and Only Once)。
二、YAGNI原則
YAGNI是 You aren't gonna need it 的縮寫,意思是"你不會需要它"。
這是"極限編程"提倡的原則,指的是你自以為有用的功能,實際上都是用不到的。因此,除了最核心的功能,其他功能一概不要部署,這樣可以大大加快開發。
它背後的指導思想,就是盡可能快、盡可能簡單地讓軟件運行起來(do the simplest thing that could possibly work)。
但是,這裏出現了一個問題。仔細推敲的話,你會發現DRY原則和YAGNI原則並非完全兼容。前者追求"抽象化",要求找到通用的解決方法;後者追求"快和省",意味著不要把精力放在抽象化上麵,因為很可能"你不會需要它"。所以,就有了第三個原則。
三、Rule Of Three原則
Rule of three 稱為"三次原則",指的是當某個功能第三次出現時,才進行"抽象化"。
這是軟件開發大家Martin Fowler在《Refactoring》一書中提出的。
它的涵義是,第一次用到某個功能時,你寫一個特定的解決方法;第二次又用到的時候,你拷貝上一次的代碼;第三次出現的時候,你才著手"抽象化",寫出通用的解決方法。
這樣做有幾個理由:
(1)省事。如果一種功能隻有一到兩個地方會用到,就不需要在"抽象化"上麵耗費時間了。
(2)容易發現模式。"抽象化"需要找到問題的模式,問題出現的場合越多,就越容易看出模式,從而可以更準確地"抽象化"。
比如,對於一個數列來說,兩個元素不足以判斷出規律:
1, 2, _, _, _, _,
第三個元素出現後,規律就變得較清晰了:
1, 2, 4, _, _, _,
(3)防止過度冗餘。如果一種功能同時有多個實現,管理起來非常麻煩,修改的時候需要修改多處。在實際工作中,重複實現最多可以容忍出現一次,再多就無法接受了。
綜上所述,"三次原則"是DRY原則和YAGNI原則的折衷,是代碼冗餘和開發成本的平衡點,值得我們在"抽象化"時遵循。
==========================================================
最後更新:2017-04-03 18:51:56