微前端软件设计原则（SOLID原则）

单一职责原则

🪐  永远不应该有多余一个原因来改变某个类

🪐   理解：对于一个类而言，应该仅有一个引起他变化的原因

🪐  应用：如果一个类拥有两种职责，那就可以将这个类分成两个类

开放封闭原则

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

🪐  理解：对于扩展开放，对于修改封闭。可以去扩展类，但不要去修改类。

🪐  应用：当需求有改动，尽量用继承或组合方式来扩展泪的功能，而不是直接修改类的代码

里氏替换原则

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

最少知识原则

🪐  只与你最直接的对象交流

🪐  理解：低耦合，高内聚

🪐  应用：做系统设计时，尽量减少依赖关系

接口隔离原则（通过接口预设一部分类型，以此限制类的实现）

🪐   一个类与另一个类之间的依赖性，应该依赖于尽可能小的接口

🪐  理解：不要对外暴露没有实际意义的接口。用户不应该依赖它不需要的接口

🪐  应用：当需要对外接口暴露时，如果是非必要对外提供，尽量删除

依赖倒置原则

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

🪐   理解： 应该面向接口编程，不应该面向实现类编程

🪐 不是说所有的类都要有一个对应的接口，而是说如果有接口尽量使用接口编程

补充设计原则

组合、聚合复用原则

🪐  当要扩展类的功能时，优先考虑组合，而不是继承。

无环依赖原则

🪐  当A模块依赖于B模块，B模块依赖于C模块，C模块依赖于A模块，此时将出现循环依赖。

在设计时避免该问题，可通过引入“中介者模式”解决。  

共同封装原则

🪐  应该将易变得类放在同一个包里，将变化隔离出来

🪐  该原则是“开放-封闭原则”的延生

共同重用原则

🪐  如果重用了包中的一个类，那么也就相当于重用了包中的所有类，我们尽可能减小包的大小。

好莱坞原则

🪐   don’t call me， I‘ll call you

🪐  “控制反转”（或者叫依赖注入）

🪐  不需要主动创建对象，而是由容器帮我们创建管理对象