設計模式六大原則：開閉原則

目錄： 

　　設計模式六大原則：單一職責原則

　　設計模式六大原則：接口隔離原則 

　　設計模式六大原則：依賴倒置原則

　　設計模式六大原則：里氏替換原則

　　設計模式六大原則：迪米特法則

　　設計模式六大原則：開閉原則

開閉原則(Open Close Principle)：

　　Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

　　軟件對象（類、模塊、方法等）應該對於擴展是開放的，對修改是關閉的。好比：一個網絡模塊，原來只服務端功能，而如今要加入客戶端功能，那麼應當在不用修改服務端功能代碼的前提下，就可以增長客戶端功能的實現代碼，這要求在設計之初，就應當將客戶端和服務端分開。公共部分抽象出來。

問題由來：

　　在軟件的生命週期內，由於變化、升級和維護等緣由須要對軟件原有代碼進行修改時，可能會給舊代碼中引入錯誤，也可能會使咱們不得不對整個功能進行重構，而且須要原有代碼通過從新測試。

解決辦法：

　　當軟件須要變化時，儘可能經過擴展軟件實體的行爲來實現變化，而不是經過修改已有的代碼來實現變化。

　　開閉原則是面向對象設計中最基礎的設計原則，它指導咱們如何創建穩定靈活的系統。開閉原則多是設計模式六項原則中定義最模糊的一個了，它只告訴咱們對擴展開放，對修改關閉，但是到底如何才能作到對擴展開放，對修改關閉，並無明確的告訴咱們。之前，若是有人告訴我"你進行設計的時候必定要遵照開閉原則"，我會覺的他什麼都沒說，但貌似又什麼都說了。由於開閉原則真的太虛了。

　　在仔細思考以及仔細閱讀不少設計模式的文章後，終於對開閉原則有了一點認識。其實，咱們遵循設計模式前面5大原則，以及使用23種設計模式的目的就是遵循開閉原則。也就是說，只要咱們對前面5項原則遵照的好了，設計出的軟件天然是符合開閉原則的，這個開閉原則更像是前面五項原則遵照程度的"平均得分"，前面5項原則遵照的好，平均分天然就高，說明軟件設計開閉原則遵照的好；若是前面5項原則遵照的很差，則說明開閉原則遵照的很差。

　　其實筆者認爲，開閉原則無非就是想表達這樣一層意思：用抽象構建框架，用實現擴展細節。由於抽象靈活性好，適應性廣，只要抽象的合理，能夠基本保持軟件架構的穩定。而軟件中易變的細節，咱們用從抽象派生的實現類來進行擴展，當軟件須要發生變化時，咱們只須要根據需求從新派生一個實現類來擴展就能夠了。固然前提是咱們的抽象要合理，要對需求的變動有前瞻性和預見性才行。

　　說到這裏，再回想一下前面說的5項原則，偏偏是告訴咱們用抽象構建框架，用實現擴展細節的注意事項而已：單一職責原則告訴咱們實現類要職責單一；里氏替換原則告訴咱們不要破壞繼承體系；依賴倒置原則告訴咱們要面向接口編程；接口隔離原則告訴咱們在設計接口的時候要精簡單一；迪米特法則告訴咱們要下降耦合。而開閉原則是總綱，他告訴咱們要對擴展開放，對修改關閉。 

爲何使用開閉原則？

　　一、只要是面向對象的編程，在開發過程當中都會強調開閉原則

　　二、是最基礎的設計原則，其餘五個設計原則都是開閉原則的具體形態

　　三、能夠提升代碼的複用性

　　四、能夠提升代碼的可維護性

如何使用開閉原則？

　　一、抽象約束

　　　　抽象對一組事物的通用描述，沒有具體的實現，也就表示它能夠有很是多的可能性，能夠跟隨需求的變化而變化。所以，經過接口或抽象類能夠約束一組可能變化的行爲，而且可以實現對擴展開放。 

　　二、元數據控件模塊行爲　　　　

　　三、制定項目章程

　　四、封裝變化

　　　　將相同的變化封裝到一個接口或抽象類中，將不一樣的變化封裝到不一樣的接口或抽象類中，不該該有兩個不一樣變化出如今同一個接口或抽象類中。

案例：

　　一個工廠生產寶馬和奧迪兩種品牌的車 

 1 internal class Program
 2 {
 3     private static void Main(string[] args)
 4     {
 5         AutomobileFactory carf = new AutomobileFactory();
 6         carf.createAuto(AutomobileFactory.AutoType.BMW);
 7         carf.createAuto(AutomobileFactory.AutoType.AUDI);
 8     }
 9 }
10 
11 internal interface IAutomobile
12 {
13 }
14 
15 internal class Audi : IAutomobile
16 {
17     public Audi()
18     {
19         Console.WriteLine("hi 我是奧迪");
20     }
21 }
22 
23 internal class BMW : IAutomobile
24 {
25     public BMW()
26     {
27         Console.WriteLine("hello 我是寶馬");
28     }
29 }
30 
31 internal class AutomobileFactory
32 {
33     public enum AutoType
34     {
35         AUDI, BMW
36     }
37 
38     public IAutomobile createAuto(AutoType carType)
39     {
40         switch (carType)
41         {
42             case AutoType.AUDI:
43                 return new Audi();
44 
45             case AutoType.BMW:
46                 return new BMW();
47         }
48         return null;
49     }
50 }

view code

　　隨着業務不斷擴展，須要生產賓利，怎麼辦？對原有工廠進行改造使其知足生產賓利的條件？對開閉原則來講，這顯然不合適。因而。。。

 1 internal class Program
 2 {
 3     private static void Main(string[] args)
 4     {
 5         IAutomobileFactory audi = new AudiFactory();
 6         audi.createAuto();
 7         IAutomobileFactory bmw = new BMWFactory();
 8         bmw.createAuto();
 9     }
10 }
11 
12 internal interface IAutomobile
13 {
14 }
15 
16 internal class Audi : IAutomobile
17 {
18     public Audi()
19     {
20         Console.WriteLine("hi 我是奧迪");
21     }
22 }
23 
24 internal class BMW : IAutomobile
25 {
26     public BMW()
27     {
28         Console.WriteLine("hello 我是寶馬");
29     }
30 }
31 
32 internal interface IAutomobileFactory
33 {
34     IAutomobile createAuto();
35 }
36 
37 internal class AudiFactory : IAutomobileFactory
38 {
39     public IAutomobile createAuto()
40     {
41         return new Audi();
42     }
43 }
44 
45 internal class BMWFactory : IAutomobileFactory
46 {
47     public IAutomobile createAuto()
48     {
49         return new BMW();
50     }
51 }

view code

參考：http://wiki.jikexueyuan.com/project/java-design-pattern-principle/principle-6.html