设计原则
单一职责原则<br>
一个类只负责完成一个职责或者功能<br>
里式替换原则<br>
子类对象能够替换程序中父类对象出现的任何地方，并且保证原来程序的逻辑行为不变及正确性不被破坏<br>
接口隔离原则<br>
接口的调用者或者使用者不应该被强迫依赖它不需要的接口<br>
依赖反转,依赖注入,依赖反转<br>
如何重构
封装与抽象
中间层
第一阶段：引入一个中间层，包裹老的接口，提供新的接口定义
第二阶段：新开发的代码依赖中间层提供的新接口
第三阶段：将依赖老接口的代码改为调用新接口
第四阶段：确保所有的代码都调用新接口之后，删除掉老的接口
设计原则
单一职责原则
基于接口而非实现编程
依赖注入
多用组合少用继承
迪米特法则
迪米特法则讲的是，不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口。
如何快速改善代码质量
关于命名
命名的关键是能准确达意。对于不同作用域的命名，我们可以适当地选择不同的长度
我们可以借助类的信息来简化属性、函数的命名，利用函数的信息来简化函数参数的命名
命名要可读、可搜索。不要使用生僻的、不好读的英文单词来命名。命名要符合项目的统一规范，也不要用些反直觉的命名
接口有两种命名方式：一种是在接口中带前缀“I”；另一种是在接口的实现类中带后缀“Impl”。对于抽象类的命名，也有两种方式，一种是带上前缀“Abstract”，一种是不带前缀。这两种命名方式都可以，关键是要在项目中统一
关于注释
注释的内容主要包含这样三个方面：做什么、为什么、怎么做。对于一些复杂的类和接口，我们可能还需要写明“如何用”
类和函数一定要写注释，而且要写得尽可能全面详细。函数内部的注释要相对少一些，一般都是靠好的命名、提炼函数、解释性变量、总结性注释来提高代码可读性
关于代码风格
函数的代码行数不要超过一屏幕的大小，比如 50 行。类的大小限制比较难确定
一行代码多长最合适？最好不要超过 IDE 的显示宽度。当然，也不能太小，否则会导致很多稍微长点的语句被折成两行，也会影响到代码的整洁，不利于阅读
善用空行分割单元块。对于比较长的函数，为了让逻辑更加清晰，可以使用空行来分割各个代码块
类中成员怎么排列？在 Google Java 编程规范中，依赖类按照字母序从小到大排列。类中先写成员变量后写函数。成员变量之间或函数之间，先写静态成员变量或函数，后写普通变量或函数，并且按照作用域大小依次排列
关于编码技巧
将复杂的逻辑提炼拆分成函数和类
通过拆分成多个函数或将参数封装为对象的方式，来处理参数过多的情况
函数中不要使用参数来做代码执行逻辑的控制
函数设计要职责单一
移除过深的嵌套层次，方法包括：去掉多余的 if 或 else 语句，使用 continue、break、return 关键字提前退出嵌套，调整执行顺序来减少嵌套，将部分嵌套逻辑抽象成函数
用字面常量取代魔法数
用解释性变量来解释复杂表达式，以此提高代码可读性
