开放封闭原则

开发封闭原则(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接口。

拒绝滥用抽象，只将经常变化的部分进行抽象。

一个利用策略模式来实现开放-封闭原则的方法：

考虑下面某个类的方法：      

public double totalPrice(Part[] parts) {

           double total = 0.0;

          for(int i = 0;i<parts.length;i++) {

               total += parts[i].getPrice();

          }         

return total;      

}     

以上函数的工作是在制订的部件数组中计算各个部件价格的总和。若Part是一个基类或接口且使用了多态，则该类可很容易地来适应新类型的部件，而不必对其进行修改。其将符合OCP      但是在计算总价格时，若财务部颁布主板和内存应使用额外费用，则将如何去做。下列的代码是如何来做的呢？这符合OCP吗？       public double totalPrice(Part[] parts) {

           double total = 0.0;

          for(int i = 0;i<parts.length;i++) {

               if(parts[i] instanceof Motherboard)

                   total += (1.45*parts[i].getPrice());

               else if(parts[i] instanceof Memory)

                   total += (1.27*parts[i].getPrice());

               else  

                 total += parts[i].getPrice();

          }

          return total;

      }     

当每次财务部提出新的计价策略，我们都不得不要修改totalPrice()方法！这并非“对更改是封闭的”。显然，策略的变更便意味着我们不得不要在一些地方修改代码的，因此不符合OCP，那麽我们该如何去做呢？      为了使用我们第一个版本的totalPrice()，我们可以将计价策略合并到Part的getPrice()方法中。      这里是Part和ConcretePart类的示例：

      public class Part {

          private double basePrice;

          public void setPrice(double price) {

              basePrice = price;

          }

         public double getPrice() {

             return basePrice;

         }

      }
     public class Motherboard extends Part {

         public double getPrice() {

             return 1.45*basePrice;

         }

      }

     public class Memory extends Part {

         public double getPrice() {

             return 1.27*basePrice;

         }     

}     

但是现在每当计价策略发生改变，我们就必须修改Part 的每个子类！      一个更好的思路是采用一个PricePolicy类，通过对其进行继承以提供不同的计价策略，那麽这里就是在运用设计模式里面的策略模式了，解决起来算是很完美了：

      public class Part {

         private PricePolicy pricePolicy;

          public void setPricePolicy(PricePolicy policy) {

              pricePolicy = policy;  

        }

         public void setPrice(double price) {

             pricePolicy.setPrice(price);

          }  

        public double getPrice() {

              return pricePolicy.getPrice();

          }

     }

     public class PricePolicy {

         private double basePrice;

          public void setPrice(double price) {

              basePrice = price;

          }

          public double getPrice() {

              return basePrice;

         }

     }

         public class SalePrice extends PricePolicy {

          private double discount;

          public void setDiscount(double discount) {

             this.discount = discount;

          }

         public double getPrice() {

             return basePrice*discount;

         }

        }

      看起来我们所做的就是将问题推迟到另一个类中，将“变化”封装在PricePolicy类里面。但是使用该解决方案，我们可通过改变Part对象，在运行期间动态地来设定计价的策略。另一个解决方案是使每个ConcretePart从数据库或属性文件中获取其当前的价格，这样相当于把“变化”封装在了属性文件里面了。