【面向對象設計原則】之開閉原則(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 "cat":
                    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 "cat":
                    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 Cat : 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）是咱們在面向對象設計過程當中必須注入潛意識的一個原則，在設計的過程當中要時時刻刻，如影隨形，一旦發現違背就要當即重構，否則代碼就會變的愈來愈不易於理解，愈來愈不易於維護了。