如需下载源码，请访问
https://github.com/fengchuanfang/Open_Closed_Principle
文章原创，转载请注明出处：
设计模式心法总则：开闭原则
开闭原则（Open-Closed Principle，OCP）是面向对象设计中“可复用设计”的基石，是设计模式最基本的法则。后面将要提到的五大设计原则和23种设计模式都可以看做是开闭原则的实现方法和手段。
1988年，勃兰特·梅耶（Bertrand Meyer）在他的著作《面向对象软件构造（Object Oriented Software Construction）》中提出了开闭原则，它的原文是这样：“Software entities should be open for extension,but closed for modification”。翻译过来就是：“软件实体应当对扩展开放，对修改关闭”。
说的通俗一点就是，已经开发好的软件实体（如类、模块、函数），在升级迭代引入新功能时，不应该修改已有的代码，而是在已有代码的基础上，添加新代码来实现。
每个公司的软件产品只要还在运营，都避免不了升级迭代，优化老功能，添加新功能，来满足用户不断膨胀的需求。
软件产品的变化无疑是个既定的事实，为了实现这种变化，我们既可以修改已有的代码，也可以保持已有的代码不变添加新代码。
就像一个工厂，原本只有生产A产品的生产线1，现因业务拓展，需要生产B产品，既可以改装一下生产线1，让它即生产A产品又生产B产品；也可以保持生产线1不变，再开展一条生产线2,生产B产品。
开闭原则要求我们要尽可能的通过保持原有代码不变添加新代码而不是通过修改已有的代码来实现软件产品的变化。
开闭原则为我们在进行软件开发设计时提供了一个准则，要求我们设计开发出的软件，在应对未来可能出现的变化时，要具备良好的拓展性，要能通过添加新代码而不是修改已有的代码来实现这种可能的变化。
开闭原则要贯穿在软件开发的各个层级中，要利用在每一个方法中，由方法组成的类中，由功能密切的类组成的模块中，由相互依存的模块组成的项目中。
下面通过一个示例让我们来体验一下开闭原则
一个工厂原本只有生产A产品的生产线1，现因业务拓展，需要生产B产品
设计一：
只有生产A产品的生产线的时候
工厂是这样的：
public class Factory {
public String prodLine(){
return "产品A";
}
}
客户是这样的：
public class Client1 {
public static void main(String args[]) {
System.out.println("我订购并收到产品："+order());
}
private static String order(){
Factory factory = new Factory();
return factory.prodLine();
}
}
运行之后，可以满足客户1的需求：
我订购并收到产品：产品A
现因业务拓展，需要加一条生产B产品的生产线
对于工厂，我们可以这么改：
public class Factory {
public String prodLine(int type) {
if(type == 0){
return "产品A";
}else{
return "产品B";
}
}
}
改完之后，我们就会发现客户1已经爆红了，生产线方法prodLine加了个参数int type，所以客户1就不能像原来那样下订单了，因为现在是混合型生产线，再下订单时需要指明需要的产品，否则生产不了。
这种让客户调整自己适应公司的改变，而公司只会增加客户的负担而不能给其带来额外利润的做法，在客户至上，客户利益大于一切的今天，无疑是十分愚蠢的。
客户1看在与公司多年合作，友谊深厚的份上，委屈一下自己勉强做下改变，以后再下订单的时候指定所需产品类型。
public class Client1 {
public static void main(String args[]) {
System.out.println("我订购并收到产品："+order());
}
private static String order(){
Factory factory = new Factory();
return factory.prodLine(0);
}
}
客户1又可以正常向工厂订购并收取产品A了
然后是客户2，工厂经过调整，已经可以生产其所需要的产品B了，可以向工厂下单了
public class Client2 {
public static void main(String args[]) {
System.out.println("我订购并收到产品："+order());
}
private static String order(){
Factory factory = new Factory();
return factory.prodLine(1);
}
}
客户2也可以正常向工厂订购并收取产品B了
以后再有新的需求，依然可以改造原有的生产线prodLine，只需根据type不同多加几个if…else…即可。
但是这样做增加了生产线方法调用的复杂性，不仅需要改变原有客户类Client1，而且对于之后新加进来客户类在调用生产线方法时，都需要适应这种复杂性，一旦参数传错，就收取不到自己所需的产品。随着新客户需求的不断增加，生产线方法中的代码也会暴增，最后就会变得极难维护。
设计二：
在工厂类Factory中保持原生产线prodLine不变，新加一个生产线prodLine1，生产产品B，如下：
public class Factory {
public String prodLine(){
return "产品A";
}
public String prodLine1(){
return "产品B";
}
}
这样改完之后，客户1不做任何更改，依然可以正常运行
只需添加客户2：Client2
public class Client2 {
public static void main(String args[]) {
System.out.println("我订购并收到产品："+order());
}
private static String order(){
Factory factory = new Factory();
return factory.prodLine1();
}
}
客户2也可以正常向工厂订购并收取产品B了
这样做可以保证客户1不做任何的更改，不需要因工厂的改变而改变自己，同时也可以满足客户2的需求。
但这就是开闭原则了吗，其实还远着呢。
这样做依然是有问题的，如果再有新的客户需求，我们依然需要在工厂类中添加生产线，会引起工厂类的爆炸导致生产线方法过多，新的客户类在调用的时候，需要在一大堆的生产线方法中选择出自己需要的那个。而且，新增的生产线方法对原有的客户类也是可见的，如果哪天客户喝大了，一不留神就有可能下错单，收错货。
设计三：到了开闭原则展示自己魅力的时候了
如果开始时，我们是这么设计的
先写个工厂接口，预知未来可能的变化，需要生产线方法，如下：
public interface IFactory {
String prodLine();
}
满足客户1的工厂FactoryA实现IFactory，生产产品A，如下：
public class FactoryA implements IFactory{
@Override
public String prodLine() {
return "产品A";
}
}
对于客户1中的代码：
public class Client1 {
public static void main(String args[]) {
System.out.println("我订购并收到产品："+order());
}
private static String order(){
IFactory factory = new FactoryA();
return factory.prodLine();
}
}
客户1中持有工厂接口IFactory的引用，指向其实现类，
运行之后，可以满足客户1的需求：
我订购并收到产品：产品A
现在公司需要拓展业务满足客户2的需求，只需添加一个工厂接口IFactory的实现类，生产B产品，如下：
public class FactoryB implements IFactory {
@Override
public String prodLine() {
return "产品B";
}
}
客户B中的代码
public class Client2 {
public static void main(String args[]) {
System.out.println("我订购并收到产品："+order());
}
private static String order(){
IFactory factory = new FactoryB();
return factory.prodLine();
}
}
运行后，可以满足客户B的需求
我订购并收到产品：产品B
这样相当于公司为每一位客户，私人订制了一个工厂，专门生产其所需要的产品，丝毫不受生产其他产品的影响，而且是保密生产，客户2所需的产品B，对于客户1是不可见的，绝对的客户利益至上。
以后再有新的需求，只需要增加工厂接口IFactory的实现类即可。
不需要改变原有的客户类中的代码，也不需要改变原有工厂类中的代码，不会导致工厂类中因生产线方法过多而爆炸式增长变得难以维护和使用，新增的工厂线方法对于新的客户类都是私人订制的，避免新增客户类时，面对一大堆工厂线方法眼花缭乱，原有的客户类对于新的工厂线方法都是不可见的，可避免原有客户类更改代码时调错方法的情况发生。
为什么要使用开闭原则？
1、保持软件产品的稳定性
开闭原则要求我们通过保持原有代码不变添加新代码来实现软件的变化，因为不涉及原代码的改动，这样可以避免为实现新功能而改坏线上功能的情况，避免老用户的流失。
2、不影响原有测试代码的运行
软件开发规范性好的团队都会写单元测试，如果某条单元测试所测试的功能单元发生了变化，则单元测试代码也应做相应的断言变更，否则就会导致单元测试运行红条。如果每次软件的变化，除了变更功能代码之外，还得变更测试代码，书写测试代码同样需要消耗工时，这样在项目中引入单元测试就成了累赘。开闭原则可以让单元测试充分发挥作用而又不会成为后期软件开发的累赘。
3、使代码更具模块化，易于维护
开闭原则可以让代码中的各功能，以及新旧功能独立存在于不同的单元模块中，一旦某个功能出现问题，可以很快地锁定代码位置作出修改，由于模块间代码独立不相互调用，更改一个功能的代码也不会引起其他功能的崩溃。
4、提高开发效率
在代码开发中，有时候阅读前人的代码是件很头疼的事，尤其项目开发周期比较长，可能三五年，再加上公司人员流动性大，原有代码的开发人员早就另谋高就，而代码写的更是一团糟，自带混淆，能走弯路不走直路。而现在需要在原有功能的基础上开发新功能，如果开闭原则使用得当的话，我们是不需要看懂原有代码实现细节便可以添加新代码实现新功能(例如示例中，我们不需要知道A产品是怎么生产的，便可以开发生产B产品的功能)，毕竟有时候阅读一个功能的代码，比自己重新实现这个功能用的时间还要长。