设计模式六大原则： 面向对象语言开发过程中，推荐的一些指导性原则(并不是强制要求的)
1. 单一职责原则（Single Responsibility Principle）
2. 里氏替换原则（Liskov Substitution Principle）
3. 依赖倒置原则（Dependence Inversion Principle）
4. 接口隔离原则（Interface Segregation Principle）
5. 迪米特法则 （Law Of Demeter）
6. 开闭原则(Open Closed Principle)
1.单一职责原则（Single Responsibility Principle）
- 单一职责原则：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。
简单来说单一职责原则就是：一个类只负责一件事儿，一个类不要让他太“累” ；
优点：拆分之后，职责变得单一
阅读简单，易于维护；
扩展升级，减少修改，直接增加类；
方便代码重用的；
总的来说就是使程序：简单--稳定--强大
缺点：单一职责的成本：类变多了；上端需要了解更多的类
衡量着使用：如果类相对稳定，扩展变化少，而且逻辑简单，违背单一职责也没关系
代码足够简单，就可以稍稍违背；
如果不同的职责，总是一起变化，这种是一定要分开的；
当然不只是类要支持单一职责原则，下面这些也要支持：
方法：方法多个分支，还可能扩展变化，最好拆分成多个方法；
类：接受输入-数据验证-逻辑计算--数据库操作--日志 为了重用，方便维护升级；
接口：也会把不同的功能接口，独立开来；
类库：把项目拆分成多个类库，重用--方便维护；
项目：一个web解决所有问题：客户端；管理后台；定时服务；远程接口； 还是要拆分；
系统：成熟互联网企业，有N多项目，有很多重复功能，IP库/日志库/监控系统/在线统计。。。；
2. 里氏替换原则（Liskov Substitution Principle）
里氏替换原则：任何使用基类的地方，都可以透明的使用其子类；也就是，继承+不改变行为；
继承：通过继承，子类拥有父类的一切属性和行为，任何父类出现的地方，都可以用子类来代替；
1 子类必须完全实现父类有的方法,如果子类没有父类的某项东西，就断掉继承；
2 子类可以有父类没有的东西，所以子类的出现的地方，不一定能用父类来代替；
3 透明，就是安全，父类的东西换成子类后不影响程序：
a 父类已经实现的东西，子类不要去new；
b 父类已经实现的东西，想改的话，就必须用virtual+override 避免埋雷；
声明变量、参数、属性、字段，最好都是基于基类的，也就是里式替换原则，能在父类声明的东西不要在子类声明；
3. 依赖倒置原则（Dependence Inversion Principle）
依赖倒置原则:高层模块不应该依赖于低层模块，二者应该通过抽象依赖，也就是要依赖抽象，而不是依赖细节；
抽象：抽象类/接口
细节：具体的类
23种设计模式，80%以上跟这个有关
依赖细节：程序写死了，不谈什么扩展；
依赖抽象，更具有通用性，而且具备扩展性；
细节多变的，抽象是稳定的；系统架构基于抽象来搭建，会更稳定更具备扩展性
面向抽象编程， 底层模块里面尽量都有抽象类/接口，
在声明参数/变量/属性的时候，尽量的都是 接口/抽象类
有人说：你说的我都懂，但是我在开发的过程中，好像没有感觉哪里需要抽象？
其实是因为你的项目还不够麻烦，，如果项目不考虑扩展变化，那确实不需要依赖倒置
4. 接口隔离原则（Interface Segregation Principle）
接口隔离原则:客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上；
实现一个接口的时候，只需要自己必须的功能；
为什么不建立一个大而全的接口，而是要拆分？
因为不能让类型实现自己没有的功能；
为什么要尽量的用同一个接口？
尽量让抽象更具备复用性；
接口拆分是随着项目进程而演变的，一直演变下去，是不是直接拆分成一个接口一个方法得了？？
如果真的一个接口一个方法，那也没意义了；
究竟该如何设计呢？ 确实需要丰富的经验和对业务的理解：
1 接口不能太大，否则会实现不需要的功能；
2 接口还是要尽量的小， 但是一致的功能是应该在一起的，密不可分的功能不要分开；
不能过度设计 要考虑清楚业务的边界；
3 接口合并：如果一个业务包含多个固定步骤，我们不应该把步骤都暴露，而是提供一个入口即可；如地图导航，里面有搜索-定位-导航接口，对于用户只要结果导航，所以要把三个接口合并；
5. 迪米特法则 （Law Of Demeter）
迪米特法则(最少知道原则):一个对象应该对其他对象保持最少的了解。
面向对象--类--类与类之间会有交互--功能模块--系统
高内聚，低耦合：高度封装，尽量少的暴露信息，类与类之间减少依赖；
只与直接的朋友通信
去掉内部依赖--降低访问修饰符
门面(外观)模式/中介者模式
6. 开闭原则(Open Closed Principle)
开闭原则:对扩展开发，对修改关闭；
如果有功能扩展变化的需求，希望是增加类而不是修改；
修改会影响原有功能，引入错误；
增加类就不会影响原有的东西；
开闭原则是原则的原则，五大原则是手段，这个是目标；
修改方法--增加方法(修改类)--增加类--增加dll--配置文件；
当然项目设计的时候，其实很难说全部都满足；任何一个项目都有自己的特点；
会在这里有所取舍；