軟件開發是"抽象化"原則（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, 4, _, _, _。
• 防止過度冗余。如果一種功能同時有多個實現，管理起來非常麻煩，修改的時候需要修改多處。在實際工作中，重復實現最多可以容忍出現一次，再多就無法接受了。

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

轉載于:https://www.cnblogs.com/huanjianlin/archive/2013/03/29/2988244.html

總結

以上是生活随笔為你收集整理的代码抽象的三原则的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。