1.开闭原则

开闭原则，看一下由

《spring5 核心原理与30个类手写实战》

一书给出的定义： 核心的几句话就是：

对修改关闭， 对扩展开放。

如何做到对修改关闭， 对扩展开放呢？首先解释一下这段话

1. 解释： 用白话就是，当产品经理又改需求了，或者添加了新功能，如果变化特别大，那我们最好做到尽可能少甚至不修改原来的逻辑代码，通过扩展功能代码替换原逻辑。

2. 如何做到：那么怎么通过扩展替换原来的逻辑呢？就是用到面向接口编程 。

给大家讲一个业务：
张三同学开学了，学校规定：同学们的书都是学校老师采购的，老师开学前会去附近书店买1000本书回来给同学们用，只有出示教师证才给报销，还得开1000本书的发票，老师还得核对书的数量对不对，张三的老师累的想砍人。
后来学校听说，学生去网上购物，凭借学生卡半价，而且学校也给报销，既可以节约学校的开销又可以节省老师的时间，以后的流程就由老师买书变成学生买书。

当没用开闭原则进行编程是这样的：
修改前：

修改后：

可以看到，老师买书逻辑，在改成由学生买书的业务逻辑，如果这要是真的业务代码，而不是现在的假代码，最起码也得在好几千行的业务代码里进行修改。应该有人进行过在好几千行的代码里进行业务逻辑修改，那感觉相当酸爽emmmm

那现在咱们改成用开闭原则进行修改（面向接口）：

业务修改前，由老师购书：

User接口（买书接口，返回需要报销的发票信息）

Teacher实现User接口

修改成由学生买书后：只需要替换一下学生对象，并新增一个学生接口就行了：

1. 新增学生类
   
2. 将老师对象替换成学生对象
   

虽然说创建User对象的时候改动了代码，但是核心业务只改动了这一段，学校和报销业务代码都没有改变，对于买书的逻辑，只是新增了一个学生类，对老师对象进行替换，重新写买书逻辑

有的人要说了，这个也要新写一个学生买书的方法，那多麻烦，还得多一个User接口，还得去实现，设计接口也挺麻烦的，我业务很熟的，直接在原业务代码里写业务改业务他不香么？

确实如果是业务代码很少很少也不复杂，就不要进行开闭原则了，因为这样直接改代码可能会更方便

但是如果好几千行的代码，如果直接写代码不做任何设计，祈祷同事不会砍死你吧。

这就是开闭原则的大概思想哈，思想这个东西不止设计业务层，实现方式也不局限于面向接口编程，在写任何代码的时候要多想，弟弟就写到这了，大佬勿喷，就算想喷也挺着吧，毕竟每个人有每个人的想法，每个人可能都是对的。