今天面試被問到程序設計的六大原則，一臉懵逼，什么程序設計六大原則，程序設計還有原則，還六大
下面這篇文章介紹的挺全，保留下來
參考一
參考二

單一職責原則——SRP（Single-Responsibility Principle）

• 定義：不要存在多于一個導致類變更的原因。通俗的說，即一個類只負責一項職責。
• 問題由來：類T負責兩個不同的職責：職責P1，職責P2。當由于職責P1需求發生改變而需要修改類T時，有可能會導致原本運行正常的職責P2功能發生故障。
• 解決方案：遵循單一職責原則。分別建立兩個類T1、T2，使T1完成職責P1功能，T2完成職責P2功能。這樣，當修改類T1時，不會使職責P2發生故障風險；同理，當修改T2時，也不會使職責P1發生故障風險。
• 所以單一職責原則有如下好處：
  1、可以降低類的復雜度，一個類只負責一項職責，其邏輯肯定要比負責多項職責簡單的多；
  2、提高類的可讀性，提高系統的可維護性；
  3、變更引起的風險降低，變更是必然的，如果單一職責原則遵守的好，當修改一個功能時，可以顯著降低對其他功能的影響。

雖然單一職責原則可以使程序更有條理，但如果有些方法只能寫在一個類中，不能分開，就不要強行符合單一職責原則了。

開閉原則——OCP（Open-Closed Principle）

• 定義：一個軟件實體如類、模塊和函數應該對擴展開放，對修改關閉。
• 問題由來：在軟件的生命周期內，因為變化、升級和維護等原因需要對軟件原有代碼進行修改時，可能會給舊代碼中引入錯誤，也可能會使我們不得不對整個功能進行重構，并且需要原有代碼經過重新測試。
• 解決方案：當軟件需要變化時，盡量通過擴展軟件實體的行為來實現變化，而不是通過修改已有的代碼來實現變化。
• 開閉原則有如下優點：
  1、按照OCP原則設計出來的系統，降低了程序各部分之間的依賴，使程序各個模塊更加獨立。
  2、當程序需要增加新的功能時，不需要對原程序進行修改，只需要在原有基礎上附加新的模塊就能實現所需要添加的功能。增加的新模塊對原有的模塊基本沒有影響，這樣就不用對原有模塊進行測試，即使出現錯誤也是新建模塊的錯誤，便于修改。

里氏替換原則——LSP（Liskov Substitution Principle）

• 定義1、如果對每一個類型為 T1的對象 o1，都有類型為 T2 的對象o2，使得以 T1定義的所有程序 P 在所有的對象 o1 都代換成 o2 時，程序 P 的行為沒有發生變化，那么類型 T2 是類型 T1 的子類型。
• 定義二、所有引用基類的地方必須能透明地使用其子類的對象。

里氏替換原則說明了子類與父類之間應該滿足的關系，子類可以去擴展父類的功能，增加方法，但是不能改變父類原有的功能。

• 子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
• 子類中可以增加自己特有的方法。
• 當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬松。
• 當子類的方法實現父類的抽象方法時，方法的后置條件（即方法的返回值）要比父類更嚴格。

依賴倒置原則——DIP（Dependence Inversion Principle）

• 定義：高層模塊不應該依賴低層模塊，二者都應該依賴其抽象；抽象不應該依賴細節；細節應該依賴抽象。

• 問題由來：類A直接依賴類B，假如要將類A改為依賴類C，則必須通過修改類A的代碼來達成。這種場景下，類A一般是高層模塊，負責復雜的業務邏輯；類B和類C是低層模塊，負責基本的原子操作；假如修改類A，會給程序帶來不必要的風險。

• 解決方案：將類A修改為依賴接口I，類B和類C各自實現接口I，類A通過接口I間接與類B或者類C發生聯系，則會大大降低修改類A的幾率
  在編程過程中盡量面向接口編程，也就是說在寫一個類前先寫一個接口，然后用一個類來實現這個接口，通過面向接口編程，我們的程序就有了很高的擴展性，降低了類與類之間的依賴性，使實現類更依賴于接口，而不是其他實現類，提高了系統的穩定性。

接口隔離原則——ISP（Interface Segregation Principle）

• 定義：客戶端不應該依賴它不需要的接口；一個類對另一個類的依賴應該建立在最小的接口上。
• 問題由來：類A通過接口I依賴類B，類C通過接口I依賴類D，如果接口I對于類A和類B來說不是最小接口，則類B和類D必須去實現他們不需要的方法。

• 解決方案：將臃腫的接口I拆分為獨立的幾個接口，類A和類C分別與他們需要的接口建立依賴關系。也就是采用接口隔離原則。
  未實現接口隔離原則如下：

  
  
  image.png
  
  

  遵守接口隔離原則后

  
  
  image.png
  
  使用時注意以下幾點：
  1、接口盡量小，但是要有限度。對接口進行細化可以提高程序設計靈活性是不掙的事實，但是如果過小，則會造成接口數量過多，使設計復雜化。所以一定要適度。
  2、為依賴接口的類定制服務，只暴露給調用的類它需要的方法，它不需要的方法則隱藏起來。只有專注地為一個模塊提供定制服務，才能建立最小的依賴關系。
  

  3、提高內聚，減少對外交互。使接口用最少的方法去完成最多的事情。

迪米特原則——（Law of Demeter）

• 定義：一個對象應該對其他對象保持最少的了解。所以迪米特法則又叫最少知道原則
• 問題由來：類與類之間的關系越密切，耦合度越大，當一個類發生改變時，對另一個類的影響也越大。
• 解決方案：盡量降低類與類之間的耦合。簡單的說，就是如果兩個類不必彼此直接通信，那么這兩個類就不應當發生直接的相互作用。如果其中一個類需要調用另一個類的某一個方法的話，可以通過第三者轉發這個調用

組合重用原則

• 定義: 要盡量使用組合,而不是繼承關系達到重用目的,

通常類的復用分為繼承復用和合成復用兩種，繼承復用雖然有實現和易實現的優點，但是它也存在如下的缺點：
1、繼承復用破壞了類的封裝性。因為繼承會將父類的實現細節暴露給子類，父類對子類是透明的，所以這種復用又稱為“白箱”復用。
2、子類與父類的耦合度高。父類的實現的任何改變都會導致子類的實現發生變化，這不利于類的擴展與維護。
3、它限制了復用的靈活性。從父類繼承而來的實現是靜態的，在編譯時已經定義，所以在運行時不可能發生變化。

所以我們可以通過將已有的對象納入新對象中，作為新對象的成員對來來實現，新對象可以調用已有對象的功能，從而達到復用。