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

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

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

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

一、DRY原則 

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

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

這個(gè)原則有時(shí)也稱為"一次且僅一次"原則（Once and Only Once）。 

二、YAGNI原則 

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

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

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

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

三、Rule Of Three原則 

Rule of three 稱為"三次原則"，指的是當(dāng)某個(gè)功能第三次出現(xiàn)時(shí)，才進(jìn)行"抽象化"。 

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

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

這樣做有幾個(gè)理由： 

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

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

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