軟件開發(fā)是"抽象化"原則（Abstraction）的一種體現(xiàn)。 

所謂"抽象化"，就是指從具體問題中，提取出具有共性的模式，再使用通用的解決方法加以處理。

開發(fā)軟件的時候，一方面，我們總是希望使用別人已經(jīng)寫好的代碼，另一方面，又希望自己寫的代碼盡可能重用，以求減少工作量。要做到這兩個目標，這需要"抽象化"。 

最近，我讀到美國程序員Derick Bailey的一篇文章，談到"抽象化"應該遵循的三個原則，覺得很有啟發(fā)。 

一、DRY原則 

DRY是 Don't repeat yourself 的縮寫，意思是"不要重復自己"。

軟件工程名著《The Pragmatic Programmer》首先提出了這個原則。它的涵義是，系統(tǒng)的每一個功能都應該有唯一的實現(xiàn)。也就是說，如果多次遇到同樣的問題，就應該抽象出一個共同的解決方法，不要重復開發(fā)同樣的功能。 

這個原則有時也稱為"一次且僅一次"原則（Once and Only Once）。 

二、YAGNI原則 

YAGNI是 You aren't gonna need it 的縮寫，意思是"你不會需要它"。 

這是"極限編程"提倡的原則，指的是你自以為有用的功能，實際上都是用不到的。因此，除了最核心的功能，其他功能一概不要部署，這樣可以大大加快開發(fā)。 

它背后的指導思想，就是盡可能快、盡可能簡單地讓軟件運行起來（do the simplest thing that could possibly work）。 

但是，這里出現(xiàn)了一個問題。仔細推敲的話，你會發(fā)現(xiàn)DRY原則和YAGNI原則并非完全兼容。前者追求"抽象化"，要求找到通用的解決方法；后者追求"快和省"，意味著不要把精力放在抽象化上面，因為很可能"你不會需要它"。所以，就有了第三個原則。 

三、Rule Of Three原則 

Rule of three 稱為"三次原則"，指的是當某個功能第三次出現(xiàn)時，才進行"抽象化"。 

這是軟件開發(fā)大家Martin Fowler在《Refactoring》一書中提出的。 

它的涵義是，第一次用到某個功能時，你寫一個特定的解決方法；第二次又用到的時候，你拷貝上一次的代碼；第三次出現(xiàn)的時候，你才著手"抽象化"，寫出通用的解決方法。 

這樣做有幾個理由： 

• 省事。如果一種功能只有一到兩個地方會用到，就不需要在"抽象化"上面耗費時間了。
• 容易發(fā)現(xiàn)模式。"抽象化"需要找到問題的模式，問題出現(xiàn)的場合越多，就越容易看出模式，從而可以更準確地"抽象化"。比如，對于一個數(shù)列來說，兩個元素不足以判斷出規(guī)律：1, 2, _, _, _, _,；第三個元素出現(xiàn)后，規(guī)律就變得較清晰了：1, 2, 4, _, _, _。
• 防止過度冗余。如果一種功能同時有多個實現(xiàn)，管理起來非常麻煩，修改的時候需要修改多處。在實際工作中，重復實現(xiàn)最多可以容忍出現(xiàn)一次，再多就無法接受了。

綜上所述，"三次原則"是DRY原則和YAGNI原則的折衷，是代碼冗余和開發(fā)成本的平衡點，值得我們在"抽象化"時遵循。

轉(zhuǎn)自 http://www./news/27106