代碼的抽象三大原則

來源:互聯網
上載者:User

本文轉載自 阮一峰的部落格,原文內容如下。 

軟體開發是"抽象化"原則(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 稱為"三次原則",指的是當某個功能第三次出現時,才進行"抽象化"。 

它的涵義是,第一次用到某個功能時,你寫一個特定的解決方案;第二次又用到的時候,你拷貝上一次的代碼;第三次出現的時候,你才著手"抽象化",寫出通用的解決方案。 

這樣做有幾個理由: 


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

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



相關文章

Cloud Intelligence Leading the Digital Future

Alibaba Cloud ACtivate Online Conference, Nov. 20th & 21st, 2019 (UTC+08)

Register Now >

Starter Package

SSD Cloud server and data transfer for only $2.50 a month

Get Started >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。