软件设计应遵循的原则

     考虑下面某个类的方法：但是现在每当计价策略发生改变，我们必须修改Part 的每个子类！
     一个更好的思路是采用一个PricePolicy类，通过对其进行继承以提供不同的计价策略，那麽这里是在运用设计模式里面的策略模式了，解决起来算是很完美了：     看起来我们所做的是将问题推迟到另一个类中，将“变化”封装在PricePolicy类里面。但是使用该解决方案，我们可通过改变Part对象，在运行期间动态地来设定计价的策略。另一个解决方案是使每个ConcretePart从数据库或属性文件中获取其当前的价格，这样相当于把“变化”封装在了属性文件里面了。

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

  以上函数的工作是在制订的部件数组中计算各个部件价格的总和。若Part是一个基类或接口且使用了多态，则该类可很容易地来适应新类型的部件，而不必对其进行修改。其将符合OCP

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

    public double totalPrice(Part[] parts) {     
          double total = 0.0;     
          for(int i = 0;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类的示例：
Java代码  收藏代码

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