软件设计原则与分层

[sweet-terry]

软件设计原则

单一职责原则

• 永远不应该有多于一个原因来改变某个类
• 理解：对于一个类而言，应该仅有一个引起它变化的原因
• 应用：如果一个类拥有了两种职责，那就可以将这个类分成两个类

开放封闭原则

• 软件实体扩展应该是开放的，但对于修改应该是封闭的
• 理解：对扩展开放，对修改封闭。可以去扩展类，但不要去修改类
• 应用：当需求有改动，尽量用继承或组合的方式来扩展类的功能，而不是直接修改类的代码

里氏替换原则

• 理解：父类一定能够被子类替换

最少知识原则

• 只与你最直接的对象交流
• 理解：低耦合，高内聚
• 应用：做系统设计时，尽量减少依赖关系

接口隔离原则

• 一个类与另一个类之间的依赖性，应该依赖于尽可能小的接口
• 理解：不要对外暴露没有实际意义的接口，用户不应该依赖它不需要的接口
• 应用：当需要对外暴露接口时，如果是非必要对外提供，尽量删除

依赖倒置原则

• 高层模块不应该依赖于低层模块，他们应该依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象
• 理解：应该面向接口编程，不应该面向实现类编程

总结

• 六大原则 SOLID（稳定的），也称 SOLID原则
• 只有满足了这六大原则，才能设计出稳定的软件架构！

[sweet-terry]

补充设计原则

组合/聚合复用原则

• 当要扩展类的功能时，优先考虑使用组合，而不是继承
• 该原则在23种经典设计模式中频繁使用
• 如：代理模式、装饰模式、适配器模式等

无环依赖原则

• 当 module A 依赖于 module B , B 依赖于 C，C依赖于A，此时将出现循环依赖
• 在设计中避免该问题，可通过引入 “中介者模式” 解决

共同封装原则

• 应该将易变的类放在同一个包里，讲变化隔离出来
• 该原则是“开放-封闭原则”的诞生

共用重用原则

好莱坞原则

DON'T REPEAT YOUSELF

KEEP IT SIMPLE

高内聚低耦合

关注点分离

DON’T NEED IT

[sweet-terry]

软件设计分层

架构种类：

1. 系统级架构
2. 应用级架构
3. 模块级架构
4. 代码级架构

系统级架构

• 设计前端首要条件： 了解前端系统于其他系统之间的关系
• 关系包括：业务关系和协作机制
• 设计后端：只需要规定于后台数据传递的机制
• 包括：API设计规则，访问授权的一个开放标准（OAuth）跳转token的验证，数据传递cookie等
• 前端与后端的关系考虑的主要因素是：前后端分离的架构设计
• 前后端分离架构其实是如何实施技术决策，用户鉴权，API接口管理和设计，API文档管理，Mock的使用，BFF（服务于前端的后端，nodejs）, 是否需要服务端渲染等

微前端

• 在一个系统内微前端是应用间的架构方案
• 在多个应用之间，微前端则是一种系统间等架构方案
• 微前端是将多个前端应用以某种形式结合在一起进行应用

1. 单实例：即同一时刻，只有一个字应用被展示，字应用具备一个完整的应用生命周期
2. 多实例： 通常基于 URL 的变化来做子应用的切换

多实例：同一时刻可展示多个子应用 通常使用 web components 方案来做子应用封装，子应用更像是一个业务组件而不是应用

应用级架构

• 应用级架构可以看作是系统级架构的细化
• 单个应用与其他外部应用的关系，微服务架构下多个应用的协作，数据交换等
• 脚手架
• 模式库
• 设计系统

模块级架构

• 这部分内容是我们开始业务编码之前进行设计，我们称为迭代

代码级架构

• 规范于原则
• 开发流程
• 代码质量以及改善
• 规范而非默契

注意

• 在开发中，注意可维护性
• 简单的代码可维护性高，越是写的抽象的代码越难维护