（轉）面向對象設計原則——開放-封閉原則

開放封閉原則(Open-Closed Principle OCP)

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

什麼意思呢？

所謂開放封閉原則就是軟件實體應該對擴展開放，而對修改封閉。開放封閉原則是全部面向對象原則的核心。軟件設計自己所追求的目標就是封裝變化，下降耦合，而開放封閉原則正是對這一目標的最直接體現。

開放封閉原則主要體如今兩個方面：

對擴展開放，意味着有新的需求或變化時，能夠對現有代碼進行擴展，以適應新的狀況。

對修改封閉，意味着類一旦設計完成，就能夠獨立其工做，而不要對類盡任何修改。

爲何要用到開放封閉原則呢？

軟件需求老是變化的，世界上沒有一個軟件的是不變的，所以對軟件設計人員來講，必須在不須要對原有系統進行修改的狀況下，實現靈活的系統擴展。

如何作到對擴展開放，對修改封閉呢？

實現開放封閉的核心思想就是對抽象編程，而不對具體編程，由於抽象相對穩定。讓類依賴於固定的抽象，因此對修改就是封閉的；而經過面向對象的繼承和多態機制，能夠實現對抽象體的繼承，經過覆寫其方法來改變固有行爲，實現新的擴展方法，因此對於擴展就是開放的。

  對於違反這一原則的類，必須經過重構來進行改善。經常使用於實現的設計模式主要有Template Method模式和Strategy 模式。而封裝變化，是實現這一原則的重要手段，將常常變化的狀態封裝爲一個類。

以銀行業務員爲例

沒有實現OCP的設計：

public class BankProcess

    {  //存款 

       public void Deposite(){}

        //取款

        public void Withdraw(){ }

        //轉帳

        public void Transfer(){}

    }

    public class BankStaff

    {

        private BankProcess bankpro = new BankProcess();

        public void BankHandle(Client client)

        {

            switch (client.Type)

            {  //存款

                case "deposite":

                    bankpro.Deposite();

                    break;

                    //取款

                case "withdraw":

                    bankpro.Withdraw();

                    break;

                    //轉帳

                case "transfer":

                    bankpro.Transfer();

                    break;

            }

        }

    }

這種設計顯然是存在問題的，目前設計中就只有存款，取款和轉帳三個功能，未來若是業務增長了，好比增長申購基金功能，理財功能等，就必需要修改BankProcess業務類。咱們分析上述設計就不能發現把不能業務封裝在一個類裏面，違反單一職責原則，而有新的需求發生，必須修改現有代碼則違反了開放封閉原則。

  從開放封閉的角度來分析，在銀行系統中最可能擴展的就是業務功能的增長或變動。對業務流程應該做爲擴展的部分來實現。當有新的功能時，不須要再對現有業務進行從新梳理，而後再對系統作大的修改。

如何才能實現耦合度和靈活性兼得呢？

那就是抽象，將業務功能抽象爲接口，當業務員依賴於固定的抽象時，對修改就是封閉的，而經過繼承和多態繼承，從抽象體中擴展出新的實現，就是對擴展的開放。

如下是符合OCP的設計：

首先聲明一個業務處理接口

public  interface IBankProcess{  void Process();}

public class DepositProcess : IBankProcess

    {

        public void Process()

        { //辦理存款業務

            Console.WriteLine("Process Deposit");

        }

}

public class WithDrawProcess : IBankProcess

    {

        public void Process()

        { //辦理取款業務

            Console.WriteLine("Process WithDraw");

        }

}

public class TransferProcess : IBankProcess

    {

        public void Process()

        { //辦理轉帳業務

            Console.WriteLine("Process Transfer");

        }

    }

public class BankStaff

    {

        private IBankProcess bankpro = null;

        public void BankHandle(Client client)

        {

            switch (client.Type)

            {   //存款

                case "Deposit":

                    userProc = new DepositUser();

                    break;

                    //轉帳

                case "Transfer":

                    userProc = new TransferUser();

                    break;

                    //取款

                case "WithDraw":

                    userProc = new WithDrawUser();

                    break;

            }

            userProc.Process();

        }

    }

這樣當業務變動時，只須要修改對應的業務實現類就能夠，其餘不相干的業務就沒必要修改。當業務增長，只須要增長業務的實現就能夠了。

設計建議：

開放封閉原則，是最爲重要的設計原則，Liskov替換原則和合成/聚合複用原則爲開放封閉原則提供保證。

能夠經過Template Method模式和Strategy模式進行重構，實現對修改封閉，對擴展開放的設計思路。

封裝變化，是實現開放封閉原則的重要手段，對於常常發生變化的狀態，通常將其封裝爲一個抽象，例如銀行業務中IBankProcess接口。

拒絕濫用抽象，只將常常變化的部分進行抽象。

本人轉自：
https://www.cnblogs.com/shaosks/archive/2012/02/02/2335749.html