这篇是软件设计原则系列文章的第一篇，之前写过一篇博客里面介绍了七种设计原则，但是将七种原则容纳到一篇文章之中总感觉哪里不对：说的太多文章就会变得冗长影响阅读体验，说的太少总感觉有的话没说完就进行下一项了，于是乎本人突发奇想为何不分开来写？更于是乎就有了“软件设计原则系列文章”，本文是个开篇。废话不多说了，Let's come to the point！
软件设计一共有七大原则，在这七大原则之上还有一个总体原则，也就是我们常说的“高内聚，低耦合”。它们之间就好比白雪公主和七个小矮人的关系，那它们叫什么名字呢？让我们先来认识一下，它们分别是：开闭原则（OCP）、依赖倒置原则（DIP）、单一职责原则（SRP）、接口隔离原则（ISP）、迪米特原则（LoD）、里氏替换原则（LSP）和合成复用原则（CARP）。今天的主角是这七个矮人中的姚明，它就是开闭原则（OCP，Open Close Principle）。
门一开一闭，眼一闭一睁，这也算个原则？
没错，但这里的开闭不是指门，而是对扩展开放对修改关闭，用扩展而不是修改来适应需求的变化。有句话说的好——唯一不变的是变化本身，应用到软件界就是需求是一定会变化的，即使原来的不变新的东西也会加进来，如果你想一劳永逸，开发的东西永远不会变，那只有一种可能——这个系统已经没人在用了。怎么证明一个软件或者系统还活着？我们来看一下身边的例子：Win10是不是会不定时地更新升级？Android和IOS等常用的手机系统是不是会经常提示你升级？我们经常玩儿的游戏是不是会经常打补丁……那什么样的代码不需要维护了呢？在我上大学的时候最火的手机品牌之一——诺基亚，当时它安装的系统塞班现在已经被淘汰，这个代码已经不需要维护了（坏了，暴露年龄了）。现在是2020年的3月份，就在两个月前的1月14日，微软官方宣布Win 7操作系统退役，从此陪伴了大家10年之久的Windows 7正式退出历史舞台，它的代码也不需要维护了，更早的像什么Windows XP啊、Windows 98啊就更不用说了（再一次暴露年龄😂），估计再过十几年的学生都不一定听说过这些操作系统。说了这么多，其实想表达的就一点：既然变化是一定要发生的，那我们应该应用什么策略以及采取什么措施来应对变化，我觉得这是所有软件设计者包括开发者应该考虑的问题。哈哈，值得庆幸的是早已有前辈为我们考虑好了这些事情，他们总结的经验经过了大量工程实践的考验并被公认为行之有效的方法，从而逐渐形成原则沉淀下来为后人所用，这就是软件设计的原则。
我们在讨论本篇文章的主角——OCP之前再来废一些话，那就是如果不遵守这七大原则能不能行？就问行！不！行！答案是可以的，没问题，代码照样能运行！那你还扯个哩个儿愣～～散了，散了，都散了，各回各家吧，博主现场翻车！～～啧啧啧……我是不是在这扯皮一会儿就知道了，下面用实际的代码来感受一下用OCP和不用OCP的差别。
我们假设一个场景：小明买车，今天小明买了一辆奔驰，开着奔驰去兜风。
public class Benz {
public void run() {
System.out.println("Benz run...");
}
}
public class Person {
private String name;
public Person(String name) {
super();
this.name = name;
}
public String getName() {
return name;
}
public void driveACar(Benz benz) {
System.out.println(getName());
benz.run();
}
}
public class OCP {
public static void main(String[] args) {
Person xiaoMing = new Person("小明");
Benz benz = new Benz();
xiaoMing.driveACar(benz);
}
}
main方法模拟的是客户端程序，Person模拟的是服务端程序，这样看起来没什么问题，确实也没什么问题。然后需求变了：小明换车了，把奔驰换成了宝马，然后开着宝马去兜风。你会说那还不简单，改一下不就行了吗？
public class BMW {// 增加一个宝马类
public void run() {
System.out.println("BMW run...");
}
}
public class Person {
private String name;
public Person(String name) {
super();
this.name = name;
}
public String getName() {
return name;
}
public void driveACar(Benz benz) {
System.out.println(getName());
benz.run();
}
public void driveACar(BMW bmw) {// 增加开宝马的方法
System.out.println(getName());
bmw.run();
}
}
public class OCP {
public static void main(String[] args) {
Person xiaoMing = new Person("小明");
// Benz benz = new Benz();
// xiaoMing.driveACar(benz);
BMW bmw = new BMW();// 修改客户端代码：注释掉原有调用开奔驰的方法，新增调用开宝马的方法
xiaoMing.driveACar(bmw);
}
}
我们来看一下这一次的需求改动需要做什么工作：首先服务端代码Person要增加一个开宝马的方法，因为原有开奔驰的方法不能传入宝马对象所以只能新增一个；其次，客户端也要改变调用的代码，因为原先调用开奔驰的方法已不满足新的需求。所以，Look一下，一个小小的需求改动会牵扯到从服务端到客户端整体的改造，所谓牵一发而动全身。也许你又会问：这样不行吗？在本例中我只是用很简单的代码来举栗子，实际项目里面代码可能会很复杂，所以需求变化可能会改很多代码，工作量比较大；另一方面，改造原有代码意味着引入风险，因为原有代码可能是经过了很长时间的“磨合”，功能已经非常稳定了，你去改造它能保证百分百不引入bug吗？很有可能你改造A功能的代码，但是却无意间影响了原有的B功能，导致原有B功能不可用或出现问题。所以，面对新的需求我们不严格要求绝对不能改动原有代码，但我们应该做到的是尽可能少的改动。拿本例来说，如果小明再换一辆奥迪呢？是不是Person又得加一个开奥迪的方法？如果我们将这些具体品牌的车抽象出一个更高层的概念——汽车类，那么你需要开什么车就传入子类（或实现类）不就可以了吗？下面我们就按照这一思路来对上述代码做改造：
public interface ICar {
/**
* 将具体的车抽象出来形成一个更高层的概念，可以是一个接口或者抽象类，
* 它里面有一个run方法，所有具体品牌的车都继承或者实现这个更高层的类。
*/
void run();
}
public class Benz implements ICar {
public void run() {
System.out.println("Benz run...");
}
}
public class BMW implements ICar{
public void run() {
System.out.println("BMW run...");
}
}
public class Person {
private String name;
public Person(String name) {
super();
this.name = name;
}
public String getName() {
return name;
}
public void driveACar(ICar car) {
System.out.println(getName());
car.run();
}
}
public class OCP {
private static ICar car;
static {
// 模拟Spring注入ICar实例，需要不同品牌的车就注入不同品牌的实例即可
car = new Benz();
}
public static void main(String[] args) {
Person person = new Person("小明");
person.driveACar(car);
}
}
这样服务提供端Person就提供一个driveACar方法即可，入参是一个接口，所有具体品牌的车都实现ICar接口，这样需要什么车就传入相关的实现类即可，在客户端需要什么车就注入一个汽车实例即可，所以面对小明不断地换车，只需要扩展ICar的实现类即可，客户端（main方法）和服务提供方（Person）都不需要改代码，这就是“对扩展开放，对修改关闭”，其实面向抽象（接口）编程就是这个道理。如果再放开一点，可以把Person也抽象成接口，这样不仅小明可以开奔驰，张三、李四都可以开，需要不同的人开车就在客户端注入不同个人的实例，这一点就不在这里用代码演示了。
所以，到这里读者应该明白什么是OCP了以及遵循OCP原则会带来哪些好处，本文也接近尾声了。最后说一下为什么在文章开头处我用“白雪公主和七个小矮人”来做比喻，目的是为了让读者记住“7”这个数字，可能你看完这个系列文章之后过一段时间会忘记一共有几大原则，今后哪天如果被面试官问到只要你脑海记住有七个小矮人就可以了。