SOLID
单一职责原则(SRP)
类中的代码行数、函数或属性过多，影响代码可读性和可维护性
类依赖的其他类过多，或依赖类的其他类过多，不符合高内聚、低耦合的设计思想
比较难给类起合适名字，很难用一个业务名词概括，或者只能用一些笼统的 Manager、Context 之类的词语来命名，说明类职责定义不够清晰
私有方法过多，我们就要考虑能否将私有方法独立到新的类中，设置为 public 方法，供更多的类使用，从而提高代码的复用性
类中大量的方法都是集中操作类中的某几个属性，那就可以考虑将这几个属性和对应的方法拆分出来
为了满足单一职责原则，是不是把类拆得越细就越好呢？答案是否定的
开闭原则(OCP)
预留扩展点
代码的扩展性会跟可读性相冲突
里式替换原则(LSP)<br>
<span style="font-weight: normal;"><font color="#d32f2f">关键点</font>：design by contract -按照协议来设计</span>
子类<font color="#d32f2f" style="">不能</font>违背父类声明要实现的功能<br>
子类<font color="#d32f2f">不能</font>违背父类对输入、输出、异常的约定
子类<font color="#d32f2f">不能</font>违背父类注释中所罗列的任何特殊说明
接口隔离原则(ISP)
<font color="#d32f2f">若为一组接口的集合时</font>，如果其中部分接口只被部分调用者使用，则需要将这部分接口隔离出来，供单独使用，不强迫调用者依赖用不到的接口
<font color="#d32f2f">若为单个接口/函数时</font>，如果部分调用者仅使用其中部分功能，则需将接口/函数拆分成更细粒度的多个接口/函数，供单独调用所需
<font color="#d32f2f">若为OOP中的接口时</font>，接口的设计要尽量单一，不要让接口的实现类和调用者，依赖不需要的接口函数
依赖反转原则(DIP)
控制反转(IOC)
依赖注入(DI)
依赖注入框架(DI Framework)
KISS
<font color="#d32f2f">不要</font>使用同事可能不懂的技术来实现代码
<font color="#d32f2f">不要</font>重复造轮子，善于使用已经有的工具类库
<font color="#d32f2f">不要</font>过度优化
YAGNI<br>
<font color="#d32f2f">不要</font>过度设计
<font color="#d32f2f" style="">并不是说不需要</font>考虑代码的扩展性
DRY
常见重复
实现逻辑重复
功能语义重复
执行流程重复
提高代码复用性(Code Reuseability)
减少代码耦合
满足单一职责原则
模块化
业务与非业务逻辑分离
通用代码下沉
继承、多态、抽象、封装
应用模板等设计模式
