Bob Tarr:一些面向对象的设计法则(4)：Open-Closed Principle

法则3：开放－封闭法则（OCP）
软件组成实体应该是可扩展的，但是不可修改的。
[ Software Entities Should Be Open For Extension, Yet Closed For Modification
]

• 
  

  开放－封闭法则

  1.开放-封闭法则认为我们应该试图去设计出永远也不需要改变的模块。

  2我们可以添加新代码来扩展系统的行为。我们不能对已有的代码进行修改。
  
  3.符合OCP的模块需满足两个标准：
  

  • 可扩展，即"对扩展是开放的"（Open For Extension）－模块的行为可以被扩展，以需要满足新的需求。
  • 不可更改，即"对更改是封闭的"（Closed for Modification）－模块的源代码是不允许进行改动的。
    

  6.我们能如何去做呢？
  

  a.抽象（Abstraction）
  
  b.多态（Polymorphism）
  
  c.继承（Inheritance）
  
  d.接口（Interface）

  7. 一个软件系统的所有模块不可能都满足OCP，但是我们应该努力最小化这些不满足OCP的模块数量。
  
  
  8.开放－封闭法则是OO设计的真正核心。
  9.符合该法则便意味着最高等级的复用性（reusability）和可维护性（maintainability）。
  

• OCP示例
  

  1. 考虑下面某类的方法：

  public double totalPrice(Part[] parts) {
      double total = 0.0;
      for (int i=0; i<parts.length; i++) {
          total += parts[i].getPrice();
      }
      return total;
  }

  2.以上函数的工作是在制订的部件数组中计算各个部件价格的总和。
  

  3.若Part是一个基类或接口且使用了多态，则该类可很容易地来适应新类型的部件，而不必对其进行修改。
  

  4.其将符合OCP

  5. 但是在计算总价格时，若财务部颁布主板和内存应使用额外费用，则将如何去做。
  
  6.下列的代码是如何来做的呢？

  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;
  }

  7.这符合OCP吗？No way!

  8.当每次财务部提出新的计价策略，我们都不得不要修改totalPrice()方法！这并非"对更改是封闭的"。显然，策略的变更便意味着我们不得不要在一些地方修改代码的，因此我们该如何去做呢？
  

  9.为了使用我们第一个版本的totalPrice()，我们可以将计价策略合并到Part的getPrice()方法中。

  10.这里是Part和ConcretePart类的示例：
  

  // Class Part is the superclass for all parts.
  public class Part {
      private double price;
      public Part(double price) (this.price = price;}
      public void setPrice(double price) {this.price = price;}
      public double getPrice() {return price;}
  }
  // Class ConcretePart implements a part for sale.
  // Pricing policy explicit here!
  public class ConcretePart extends Part {
      public double getPrice() {
      // return (1.45 * price); //Premium
      return (0.90 * price); //Labor Day Sale
      }
  }
  

  11. 但是现在每当计价策略发生改变，我们就必须修改 Part 的每个子类！
  
  12.一个更好的思路是采用一个 PricePolicy 类，通过对其进行继承以提供不同的计价策略：
  

  // The Part class now has a contained PricePolicy object.
  public class Part {
      private double price;
      private PricePolicy pricePolicy;
      public void setPricePolicy(PricePolicy pricePolicy) {
          this.pricePolicy = pricePolicy;}
      public void setPrice(double price) {this.price = price;}
      public double getPrice() {return pricePolicy.getPrice(price);}
  }
  
  /**
  * Class PricePolicy implements a given price policy.
  */
  
  public class PricePolicy {
      private double factor;
      public PricePolicy (double factor) {
          this.factor = factor;
      }
      public double getPrice(double price) {return price * factor;}
  }

  
  

  13.看起来我们所做的就是将问题推迟到另一个类中。但是使用该解决方案，我们可通过改变Part对象，在运行期间动态地来设定计价的策略。
  

  14.另一个解决方案是使每个ConcretePart从数据库或属性文件中获取其当前的价格。
  

With this solution we can dynamically set pricing policies at runtime by changing the PricePolicy object that an existing Part object refers to.

l Of course, in an actual application, both the price of a Part and its associated PricePolicy could be contained in a database

• 单选法则
  

  单选法则（the Single Choice Principle）是OCP的一个推论。
  
  无论在什么时候，一个软件系统必须支持一组备选项，理想情况下，在系统中只能有一个类能够知道整个的备选项集合。