软件(工具类)设计原则

单一职责原则

永远不应该有多于一个原因来改变某个类/方法

如果一个类/工具方法，有两种职责，那就应该拆分抽离成两个类/工具方法

🌰： 确认按钮，需要校验用户名和密码，那校验方法应该分成单独的校验 如果一个校验方法里，写校验用户名校验密码 后期维护如报错需要到方法里找到具体报错的代码块对应的功能，以及一个方法会很复杂

开放封闭原则

软件实体扩展应该是开放的，但对于修改应该是封闭的

可以扩展类/工具方法，但不要去修改类/工具方法的内部逻辑

🌰： 需求改动新增时，尽量用继承和组合的方式扩展类/工具方法 如上的校验方法，现在需要增加校验图形验证码，不应该直接去修改校验用户名的方法或校验密码的方法，而是用组合的形式，增加一个校验验证码方法，校验通过true/false，来组合其他校验方法

优先考虑组合，再是继承

如：设计模式中的代理模式、装饰模式、适配器模式

里氏替换原则

父类一定能够被子类替换

在面向对象的时候会用到，在函数式编程里比较少 js主要还是函数式编程，所以了解即可

最少知识原则

只与最直接的对象交流

低耦合，高内聚，类/方法只操作最少的对象/变量，并且尽量不操作对象 只抛出状态

接口隔离原则

一个类与另一个类的依赖，依赖尽可能小的接口

接口： 通过接口去预设一部分类型，然后来限定一个类是怎样实现的？？

接口就是工具类抛出的方法？

依赖倒置原则

高层模块不应该依赖于底层模块，他们依赖于抽象。抽象不应该依赖于细节，细节应该依赖于抽象

面向接口编程，不应该面向类编程

编程时使用接口定义的类型和逻辑，而不关心类内部定义的类型和逻辑

以上6大原则首字母拼起来是SOLID(稳定的)，所以称作SOLID原则

目标是：利于扩展、利于维护、稳定的架构。足够简单又不失扩展性，避免过度封装

软件(工具类)设计分层

架构是个很大的容器，内部需要拆封，这就是分层

• 系统级架构
• 应用级架构
• 模块级架构
• 代码级架构

其实跟我们开发单页面应用时要考虑路由和文件目录怎么放类似 需要按业务分出包、模块、页面(代码) 这里体现到整个项目的系统，系统、应用、模块、代码(页面)

系统级架构

管理整个系统，如前后端通信，前端与第三方系统集成

前端系统与其他系统(后端、第三发SDK)间的关系

如前后端通信：设计api通用头通用体、错误处理、授权、token验证、数据cookie等

在微前端系统内，除了上面那些设计，还需要管理子应用

微前端设计方向

• 单实例，只有一个子应用(即不会多开应用)被展示，子应用具备完整的应用生命周期
• 多实例，同一时刻可展示多个子应用，使用web Components方案做子应用封装，子应用更像是一个业务组件而不是应用

应用级架构

应用级架构可以看作是系统级架构的细化

• 设计通用的子应用脚手架
• 设置通用的子应用工具库
• 处理单个子应用于其他子应用或主应用的关系，即子应用之间的相互通信 (如iframe的postmessage)

模块级架构

正常迭代业务需求的时候在子应用如何最好的实现的设计方案

一般为具体的开发者考虑，前提是架构让新建业务模块够简单

代码级架构

架构一般提出规范和原则

子应用也不能是完全自由的开发，还是要按照架构提出的规范和通用工具进行