设计模式之——六个“设计原则”
前言：
最近在看设计模式，本文仅作为第一次学习设计模式的笔记。
仅作为学习参考。如有不足，希望各位大神能指出，我修改。
另外，所有的设计原则不是绝对的，要根据实际项目作出相应的妥协和调整才能达到最好的效果。
本文仅说明理论，具体的 需要“代码量的积累”和“写前的思考” 才能实现。
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后 程序员小白，
第一次投稿还是有点紧张呢。。
如果哪里有异议，希望各位大神指出，我修改。
哈哈哈
