前言：
最近在看设计模式，本文仅作为第一次学习设计模式的笔记。
仅作为学习参考。如有不足，希望各位大神能指出，我修改。
另外，所有的设计原则不是绝对的，要根据实际项目作出相应的妥协和调整才能达到最好的效果。
本文仅说明理论，具体的 需要“代码量的积累”和“写前的思考” 才能实现。
1. 单一职责原则：SRP
定义：应该有且仅有一个原因引起类的变更。
即 “一个职责一个接口”。
职责分明，结构清晰。例如：用户的属性和用户的行为，需要分开写成两个接口。
一个为用户的行为，一个为用户的属性。原话：There should never be more than one reason for a class to change.
好处：
- 降低类的复杂性
- 可读性提高
- 可维护性提高
- 耦合性降低，变更引起的风险降低
2. 里氏替换原则：LSP
定义：只要父类能出现的地方子类就可以出现。
其中包括4层：
1.子类必须完全实现父类的方法
2.子类可以有自己的个性
3.覆盖或实现父类的方法时输入参数可以被放大
4.覆写或实现父类的方法时输出结果可以被缩小目的：增加程序的健壮性，添加子类，原有子类还可以继续运行。
传递不同的子类完成不同的业务逻辑。
3. 依赖倒置原则：DIP
含义：
1.高层模块不能依赖底层模块，模块都应该依赖其抽象
2.抽象不应该依赖细节
3.细节应该依赖抽象实现：
1.模块间依赖抽象，实现类之间不发生直接的依赖关系，其依赖关系通过接口或抽象类产生的
2.接口或抽象类不依赖于实现类
3.实现类依赖接口或抽象类好处：减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。
写法：如何模板依赖抽象？
1.构造函数传递依赖对象
2.Setter方法传递依赖对象
3.接口声明依赖对象最佳实践：
1.每个类尽量都有抽象类或接口
2.变量的表面类型尽量是接口或者是抽象类
3.任何类都不应该从具体类派生
4.尽量不要覆写基类的方法
4. 接口隔离原则：ISP
定义：客户端应仅依赖它需要的接口
1.客户端不应该依赖它不需要的接口
2.类间的依赖关系应该建立在最小的接口上写法：
1.接口要尽量小，职责单一，符合单一职责。
2.通过业务逻辑压缩接口中的public方法（满身筋骨肉）最佳实践：
1.一个接口只服务于一个子模块（业务逻辑）
2.通过业务逻辑压缩接口中的public方法（满身筋骨肉）
3.已经污染了的接口，尽量去修改，风险大用适配器模式。
5. 迪米特法则：LoD
又叫“最小知识原则”
定义：一个对象应该对其他的对象有最少的了解。
即 一个类应该对自己需要耦合或调用的类知道得最少。四层含义：
1.只与直接的朋友交流
2.朋友间也是有距离的
3.是自己的就是自己的
4.谨慎使用Serializable写法：编写时 反复斟酌：
1.是否可以减少public的方法和属性
2.是否可以加上private、protected、package-private
3.是否可以加上final（防止被继承）
6. 开闭原则：OCP
原话：Software entities like classes,modules and functions should be open for extendsion but closed for modifications.
直译：软件实体应该对扩展开放，对修改关闭。
实体包括：逻辑模块、抽象和类、方法
定义：开闭原则是对前5个原则的总结，前五个原则对开闭原则的具体解释。
写法：
1.抽象约束
2.元数据（配置参数，来源于数据库、本地文件）控制子模块
3.指定项目章程
4.封装变化好处：
1.减少测试压力
2.提高代码复用性
3.提高项目可维护性
4.面向对象开发的要求
开闭原则是项目的最终目标，不可能百分百做到，但朝着这个方向努力，可以改善架构，永远拥抱‘变化”，百变我不怕。
作为一名 95后 程序员小白，
第一次投稿还是有点紧张呢。。
如果哪里有异议，希望各位大神指出，我修改。
哈哈哈
