架构师训练营 - 第二周学习总结

对象具有状态（时间）、行为（方法）和标识（唯一）。

面向对象三要素：封装（隐藏细节定义接口）、继承、多态。

框架与工具的区别：

• 开发基于框架进行，不需要主动调用框架，框架自动运行调用应用程序；

• 工具需要应用程序在代码中主动调用

面向对象设计目标：高内聚、低耦合

• 易扩展：易于扩展新功能

• 更强壮：不容易被粗心的程序员破坏

• 可移植：能够运行在多样的环境中

• 更简单：容易理解、容易维护

坏软件的臭味：

• 僵硬：依赖太多、导致连锁改动

• 脆弱：修改会导致无关的地方出现错误

• 不可移植

• 导致误用的陷阱

• 晦涩、过度设计、复制的代码

OOD 原则一：开/闭原则（OCP）

• 对修改关闭

• 对扩展开发

• 不需要修改软件实体类就应该实现功能的扩展，关键在于如何抽象

OOD 原则二：依赖倒置原则（DIP）

• 高层模块不能依赖于低层模块，大家都依赖抽象

• 抽象不能依赖实现，而是实现依赖抽象

• 好莱坞原则

OOD 原则三：李氏替换原则（LSP）

• 子类型必须能替换掉他们的父类型

• 必须符合 IS-A 关系

• 能否替换要基于使用场景

OOD 原则四：单一职责原则（SRP）

• 一个职责是一个引起变化的原因

• 一个类应该只有一个引起他变化的原因

• 区分类的方法：分清职责

OOD 原则五：接口分离原则（ISP）

• 不应该强迫应用程序依赖他们不需要的方法

• ISP 和 SRP 都是强调“内聚性”

总结

• 开闭原则的目标是保持结构稳定，易扩展新的实现。当一个需求有多种实现的时候可以采用多种设计模式通过定义统一接口对实现进行分离，避免代码紧耦合。

• 依赖倒置原则有利于保持高层模块的稳定，屏蔽底层模快的变更影响。

• 单一职责原则适用类，方法。比如我们某些方法上添加一个参数已满足新需求，但是这个参数可能导致该方法内出现了两种不同的业务逻辑，这时候就该新建一个方法，如果它们有重复代码，可以考虑进行抽取公共方法，但是并不建议一开始就抽取去重，需要基于一定需求数量才能确定如何抽取共性形成公用方法。

• 接口分离原则在我们的开发中往往容易忽略，基于 springboot 的 web 业务代码往往是 controller service cache sqlMapper 几个组成，我们通常开始都是从 sql 文件出发，再写一个 service 接口一个实现类，然后定义前台和后台两个 Controller，它们调用同一个 service 类，service 类里面就存在了前台和后台的业务，对两个 controller 都暴露了不必要的实现，这里 service 就应该定义两个接口区分前后台业务；实现类最好也定义两个，同样的查询前台访问量大，需要缓存；而后台需要实时数据，可以直接查询数据库。如果放在一个 service 实现类可能导致方法混用，可维护性变差。如果采用两个 service 实现类，在后台 service 里面可能都不需要 cache 相关模块，代码更简洁明了。