程序設計7大原則


1、單一職責原則(SRP):就一個類而言,應該僅有一個引起它變化的原因。

解釋:

  • 如果一個類承擔的職責過多,就等於把這些職責耦合在一起,一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計,當變化發生時,設計會遭受到意想不到的破壞。
  • 軟件設計真正要做的許多內容,就是發現職責並把那些職責相互分離。如果你能夠想到多於一個的動機去改變一個類,那么這個類就具有多於一個的職責。

 

2、開放-封閉原則:軟件實體(類、模塊、函數等等)應該可以擴展,但是不可以修改。

解釋:

  • 對於擴展是開放的,對於更改是封閉的。我們設計程序要把擴展預留好,根據需求的改變去增減擴展,而不是一旦需求有變化就去修改整個程序,或是推倒重來。
  • 我們希望的是開發工作展開不久就知道可能發生的變化。查明可能發生變化所等待的時間越長,要創建正確的抽象就越困難。

 

3、依賴倒轉原則:

  1. 高層模塊不應該依賴低層模塊,兩個都應該依賴抽象
  2. 抽象不應該依賴細節,細節應該依賴抽象

解釋:

  • 面向過程開發時,為了使常用代碼可復用,一般都會把這些常用代碼寫成許許多多函數的程序庫,做新項目時去調用這些低層的函數,這也就叫做高層模塊依賴低層模塊。
  • 比如電腦的CPU、內存、硬盤都需要依賴具體的主板,主板一壞,所有部件都沒用了,這顯然不合理。反過來,如果內存壞了,也不應該造成其他部件不能用才對。而如果高層模塊或低層模塊都依賴於抽象,具體一點就是接口或抽象類,只要接口是穩定的,那么任何一個的更改都不用擔心其他受影響,這使得無論高層模塊還是低層模塊都可以很容易被復用。

 

4、里氏代換原則:

  • 一個軟件實體如果使用的是一個父類的話,那么一定適用於其子類,而且它察覺不出父類對象和子類對象的區別。也就是說,在軟件里面,把父類都替換成它的子類,程序的行為沒有變化,簡單的說,子類型必須能夠替換掉它們的父類型。

解釋:

  • 子類擁有父類所有非private的行為和屬性。鳥會飛,而企鵝不會飛。盡管在生物學分類上,企鵝是一種鳥,但在編程世界里,企鵝不能以父類——鳥的身份出現,因為前提說所有鳥都能飛,而企鵝飛不了,所以,企鵝不能繼承鳥類。

 

5、迪米特法則(最少知識原則):

  • 如果兩個類不必彼此直接通信,那么這兩個類就不應當發生直接的相互作用。如果其中的一個類需要調用另一個類的某一個方法的話,可以通過第三者轉發這個調用。

解釋:

  • 迪米特法則首先強調的前提是在類的結構設計上,每一個類都應當盡量降低成員的訪問權限,也就是說,一個類包裝好自己的private狀態,不需要讓別的類知道的字段或行為就不要公開。
  • 迪米特法則其根本思想,是強調了類之間的松耦合。類之間的耦合越弱,越有利於復用,一個處在弱耦合的類被修改,不會對有關系的類造成波及。

 

6、合成/聚合復用原則:盡量使用合成/聚合,盡量不要使用類繼承。

  • 聚合表示一種弱的‘擁有’關系,體現的是A對象可以包含B對象,但B對象不是A對象的一部分;
  • 合成則是一種強的‘擁有’關系,體現了嚴格的部分和整體的關系,部分和整體的生命周期一樣。

解釋:

  • 優先使用對象的合成/聚合將有助於你保持每個類被封裝,並被集中在單個任務上。這樣類和類繼承層次會保持較小規模,並且不太可能增長為不可控制的龐然大物。

 

7、敏捷開發原則:不要為代碼添加基於猜測的、實際不需要的功能。如果不清楚一個系統是否需要某種模式,一般就不要急於去實現它,事實上,在需要的時候通過重構實現這個模式並不困難,只有在真正需要的時候,把原來的代碼重構才有意義。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM