開閉原則是面向對象設計的一個重要原則，其定義如下： 開閉原則(Open-Closed Principle, OCP)：一個軟體實體應當對擴展開放，對修改關閉。即軟體實體應儘量在不修改原有代碼的情況下進行擴展。 在軟體的生命周期內，因為變化、升級和維護等原因需要對軟體原有代碼進行修改時，可能會給舊代碼 ...
開閉原則是面向對象設計的一個重要原則，其定義如下：
開閉原則(Open-Closed Principle, OCP)：一個軟體實體應當對擴展開放，對修改關閉。即軟體實體應儘量在不修改原有代碼的情況下進行擴展。
在軟體的生命周期內，因為變化、升級和維護等原因需要對軟體原有代碼進行修改時，可能會給舊代碼中引入錯誤，也可能會使我們不得不對整個功能進行重構，並且需要原有代碼經過重新測試。那麼勢必會對軟體的開髮帶來額外的風險和成本， 這是OCP原則要規範設計的一個主要原因，所有的設計原則都是對軟體的開發，設計以及維護帶來好處的，OCP也不例外。
OCP原則是面形對象軟體設計的基本原則，其旨在指導如何構建穩定的，靈活的，易於維護的軟體。其實這個原則也是我們面向對象設計的一個終極要求，更是一個引導，在軟體設計過程中要達到OCP原則其實你需要很好的遵守其他的設計原則，換句話說如果其它的設計原則都達到了那麼OCP原則自然就符合了，也就是說OCP原則是其他原則綜合使用的一個考量，一個檢驗。
假如我們要設計一個叫做動物的類（Animal）在這個類中我們有一個方法叫Sound， Sound 方法主要用於發出動物的叫聲，通常我們的設計代碼如下：
public class Animal { public void Sound(string animal) { switch (animal) { case "dog": System.Console.WriteLine("woof woof woof..."); break; case "cate": Console.WriteLine("miaow miaow miaow..."); break; } } }
客戶端的調用代碼如下：
class Program { static void Main(string[] args) { Animal animal=new Animal(); animal.Sound("dog"); Console.ReadKey(); } }
調用返回的結果：
這樣看起來似乎很完美，如果想要什麼動物發生客戶端就傳入該動物的名字然後調用Sound方法就可以了。 客戶今天只養了兩種動物，狗和貓，如果有一天他在養一頭羊，他想聽到羊的叫聲怎麼辦呢？ 直接的想法是在Sound的方法中加一個case子句，寫上羊的叫聲如下：
public class Animal { public void Sound(string animal) { switch (animal) { case "dog": System.Console.WriteLine("woof woof woof..."); break; case "cate": Console.WriteLine("miaow miaow miaow..."); break; case "sheep": Console.WriteLine("mee-mee mee-mee mee-mee..."); break; } } }
客戶端調用如下：
static void Main(string[] args) { Animal animal=new Animal(); animal.Sound("sheep"); Console.ReadKey(); }
輸出：
這看起來似乎是很完美，但是我們回過頭想一下，好像哪裡不對勁，如果後面客戶需要加更多的動物怎麼辦呢？，是不是這個case要寫很長很長，Sound方法要每次都要修改，每次都要全部編譯整個工程還要重新部署所有的代碼，這中間的風險很大，很容易出現操作上的失誤，或者代碼修改出現bug，要命的是每次都要把整個代碼重新測試一遍，給升級帶來了很多的工作量，以及潛在的風險。其實再回頭看看，我們這個設計是違反OCP原則的， OCP告訴我們對“修改關閉，對擴展開放“，很顯然我們這裡修改了代碼。同時也違背了SRP原則“一個類或方法只負責乾一件事情“，顯然Sound 犯法的職責太多。那麼我們有沒有辦法來重構代碼，讓其遵守這些原則，每次修改該最少的代碼即儘可能的減少工作量呢？ 答案是肯定的。
我們抽取一個介面叫IAnimal：
public interface IAnimal { void Sound(); }
再分別定義三個類 Dog, Cate 和Sheep 並繼承IAnimal 介面：
public class Dog : IAnimal { public void Sound() { Console.WriteLine("woof woof woof..."); } } public class Cate : IAnimal { public void Sound() { Console.WriteLine("miaow miaow miaow..."); } } public class Sheep:IAnimal { public void Sound() { Console.WriteLine("mee-mee mee-mee mee-mee..."); } }
客戶端如果想聽到狗的叫聲的代碼調用如下：
static void Main(string[] args) { IAnimal animal=new Dog(); animal.Sound(); Console.ReadKey(); }
輸出：
這下是不是比開始好了很多，並且他還很好的滿足了單一職責原則（SRP），每個類只負責一種動物發出的聲音，職責單一了， 但是我們發現如果我們想聽到貓的叫聲還是要修改Main方法中的調用代碼， 還要編譯部署，風險還是有點大，工作量還是有點大，那麼我們能不能不修改代碼只需要改個配置來達到修改Main方法調用的結果呢？這樣每次就不用編譯只需要修改一下配置就好了呢？ 答案是肯定的， 我們利用反射加配置就可以了。 這裡我們先加一個工具類用於反射。代碼如下：
public class ObjectBuildFactory<T> { public static T Instance(string key) { Type obj = Type.GetType(key); if (obj == null) return default(T); T factory = (T)obj.Assembly.CreateInstance(obj.FullName); return factory; } }
寫配置文件如下：
<appSettings> <add key="Animal" value="ConsoleApp1.Dog"/> </appSettings>
調用並通過反射創建對象，調用Dog的叫聲如下：
static void Main(string[] args) { string key = ConfigurationManager.AppSettings["Animal"]; IAnimal animal = ObjectBuildFactory<IAnimal>.Instance(key); animal.Sound(); Console.ReadKey(); }
輸出：
好瞭如果希望聽到羊的叫聲，只需要改一下我們的配置文件就可以了：
<appSettings> <add key="Animal" value="ConsoleApp1.Sheep"/> </appSettings>
其它的代碼不需要任何修改直接運行輸出如下：
好了這回滿足OCP了。
那麼好瞭如果客戶期望在增加一種動物，我們應該怎麼辦呢？ 這下就變得非常簡單了，我們需要如下兩個步驟來完成：
1.增加一個類繼承IAnimal介面並實現Sound方法。
2.修改配置文件。
例如我們增加一個動物鴨子代碼如下：
public class Duck : IAnimal { public void Sound() { Console.WriteLine("quack quack quack..."); } }
配置：
<appSettings> <add key="Animal" value="ConsoleApp1.Duck"/> </appSettings>
輸出：
很簡單達到了我們的設計目的。
總結：開閉原則（OCP）是我們在面向對象設計過程中必須註入潛意識的一個原則，在設計的過程中要時時刻刻，如影隨形，一旦發現違背就要立即重構，不然代碼就會變的越來越不易於理解，越來越不易於維護了。
