设计模式
设计模式六大原则
面向对象语言开发过程中，推荐的一些指导性原则 没有明确的招数，而且也经常会被忽视/违背 也是前辈总结，也是为了站在前辈的肩膀上
- 单一职责原则（Single Responsibility Principle）
- 里氏替换原则（Liskov Substitution Principle）
- 依赖倒置原则（Dependence Inversion Principle）
- 接口隔离原则（Interface Segregation Principle）
- 迪米特法则 （Law Of Demeter）
- 开闭原则 (Open Closed Principle)
单一职责原则（Single Responsibility Principle）
单一职责原则：类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。
方法级别的单一职责原则：一个方法只负责一件事儿（职责分拆小方法，分支逻辑分拆）
类级别的单一职责原则：一个类只负责一件事儿
类库级别的单一职责原则：一个类库应该职责清晰
项目级别的单一职责原则：一个项目应该职责清晰(客户端/管理后台/后台服务/定时任务/分布式引擎)
系统级别的单一职责原则：为通用功能拆分系统(IP定位/日志/在线统计)
里氏替换原则（Liskov Substitution Principle）
里氏替换原则：任何使用基类的地方，都可以透明的使用其子类
1 父类有的，子类是必须有的；
如果出现了子类没有的东西，那么就应该断掉继承；
(再来一个父类，只包含都有的东西)
2 子类可以有自己的属性和行为
子类出现的地方，父类不一定能代替
3 父类实现的东西，子类就不要再写了，(就是不要new隐藏)
有时候会出现意想不到的情况，把父类换成子类后，行为不一致
如果想修改父类的行为，通过abstract/virtual
声明属性、字段、变量，尽量声明为父类(父类就能满足)
依赖倒置原则（Dependence Inversion Principle）
依赖倒置原则:高层模块不应该依赖于低层模块，二者应该通过抽象依赖 依赖抽象，而不是依赖细节
抽象：接口/抽象类--可以包含没有实现的元素
细节：普通类--一切都是确定的面向抽象编程：尽量的使用抽象，80%的设计模式都是跟抽象有关
属性 字段 方法参数 返回值。。。尽量都是抽象
接口隔离原则（Interface Segregation Principle）
接口隔离原则:客户端不应该依赖它不需要的接口； 一个类对另一个类的依赖应该建立在最小的接口上；
接口到底该如何定义？
1 既不能是大而全，会强迫实现没有的东西，也会依赖自己不需要的东西
2 也不能一个方法一个接口，这样面向抽象也没有意义的
按照功能的密不可分来定义接口，
而且应该是动态的，随着业务发展会有变化的，但是在设计的时候，要留好提前量，避免 抽象的变化 3 接口合并 Map--定位/搜索/导航 这种属于固定步骤，业务细节，尽量的内聚，在接口也不要暴露太多业务细节
迪米特法则 （Law Of Demeter）
迪米特法则(最少知道原则):一个对象应该对其他对象保持最少的了解。只与直接的朋友通信。
类与类之间的关系：
纵向：继承≈实现(最密切)
横向：聚合> 组合> 关联> 依赖(出现在方法内部)高内聚低耦合
迪米特法则，降低类与类之间的耦合
只与直接的朋友通信，就是要尽量避免依赖更多类型
基类库(BCL--框架内置的)的类型除外
迪米特，也会增加一些成本
迪米特,依赖别人更少，让别人了解更少
开闭原则 (Open Closed Principle)
开闭原则:对扩展开发，对修改关闭
修改：修改现有代码(类)
扩展：增加代码(类)面向对象语言是一种静态语言，最害怕变化，会波及很多东西 全面测试
最理想就是新增类，对原有代码没有改动，原有的代码才是可信的
开闭原则只是一个目标，并没有任何的手段，也被称之为总则