开放封闭原则(The Open-Closed Principle 、OCP)

我通常强调抽象依赖原则：为了应对需求变化，代码中要尽可能地使用(依赖)抽象类型，而非具体类。而不把开放封闭原则(The Open-Closed Principle 、OCP)作为重点加以介绍，主要是因为开放封闭原则容易引起一些误解。

★Software entities(classes ，modules，functions，，etc.) should be open for extension，but closed formodification.一个软件实体(类、模块、函数等等)应对扩展开放，对修改关闭。

1.对扩展开放

对扩展开放”意味着什么？在Java中有类A，我们可以方便的创建A的新的子类型SubA，而且子类型SubA可以定义新的（A中没有的）操作。这是OOP中很容易做到的事情，也是A对扩展开放的主要方面。即

• 类A的派生
  
• SubA的扩展继承

问题是，A自己可以增加以前没有的新的操作吗？换言之，A能够增加新接口吗？这是一个非常棘手的问题(也是Java 8 搞出default方法的原因)，即程序设计时，面向对象技术不能够很好解决为类型增加新接口——所以需要访问者模式。

对函数的扩展，我们可以归结到override。

2.对修改关闭

对修改关闭，意味着你发布一个已经完成的类，那就不要轻易去修改它的接口。当我们具体到一个方法的时候，注意，方法的接口，是使用该方法的用户所需要知道的所有信息，包括方法头(方法原型)、和非常重要的说明文档——用户怎样使用该方法。

这里涉及两个问题：

• 接口与实现的分离。既然接口与实现是分离的，对修改关闭当然仅仅要求对接口的修改关闭。所以，我们能够自由地修改其实现。
  
• 哪些对实现的修改，涉及到接口？典型的例子是分支结构，

    public static Door getObject(String typeName){//int ID        if(typeName.equals("D1")){            return new D1();        }else if(typeName.equals("D2")){            return new D2();        }else{            return null;        }    }

增加新的分支，不会涉及 getObject方法头的修改——但这不意味着方法的接口没有受到影响。对于形参的验证（这里 return null代替了验证）也是用户怎样使用该方法的一部分——方法的接口的一部分。换一种方式说，假定getObject的形参的验证，字符串D1和D2是合法的参数，其他为非法参数；增加新的分支后，字符串D1、D2和D3是合法的参数，这就意味着方法的前置条件发生了变化，因而接口被修改。

大多数情况下，我们编程时比较难以细致地考虑，对实现的修改是否会影响接口，因此，在讨论对修改关闭时，很多人会一言以蔽之地说，不要对源代码有任何修改。

如果你能够清楚知道对实现的修改不会影响接口，你可以自由地修改其实现，如对某算法有更好的实现的时候。

3.封装变化

“需求总是变化”，而封装变化，OCP仅仅意味着使用一个大概念来涵盖/容纳可能出现的变化。例如你的系统中养猫养狗，那么养动物就涵盖了未来你养乌龟；如果未来你养花，就需要更大的概念...按照设计忠告——父类型通常设计成抽象类型，所以我们直接呈上了依赖抽象类型作为原则。