前端框架中有多种设计模式：
- 单例模式
- 原理：保证一个类仅有一个实例，并提供一个访问它的全局访问点。在前端，例如一个全局的日志记录器或者配置对象可以是单例。
- 优点：
- 节省内存，因为只有一个实例存在，避免了频繁创建和销毁对象的开销。
- 提供了一个全局的访问点，方便在不同的组件中共享数据或状态。
- 缺点：
- 可能会导致代码的耦合度增加，因为多个部分依赖于这个单例对象。
- 不利于单元测试，由于其全局唯一的特性，在测试时可能会互相干扰。
- 使用案例：在Vuex或者Redux中，Store是单例的。它存储应用的状态，所有组件都可以访问和修改这个状态，确保数据的一致性。
- 观察者模式
- 原理：定义了一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都会得到通知并自动更新。
- 优点：
- 实现了松耦合，被观察者和观察者之间的依赖关系比较灵活，便于代码的维护和扩展。
- 可以实现实时的数据更新，在数据变化时能及时通知相关部分进行处理。
- 缺点：
- 过度使用可能会导致性能问题，因为每次数据更新都会触发一系列的通知和更新操作。
- 可能会出现循环依赖的情况，导致系统的复杂性增加。
- 使用案例：在前端框架中，数据绑定机制常常使用观察者模式。如Vue.js中的响应式数据，当数据（被观察者）发生变化时，与之绑定的DOM元素（观察者）会自动更新。
- 工厂模式
- 原理：定义一个创建对象的接口，但让子类决定实例化哪个类。在前端可以用于创建不同类型的UI组件。
- 优点：
- 代码的可维护性高，将对象的创建和使用分离，便于修改创建对象的逻辑。
- 提高了代码的复用性，根据不同的条件创建相似类型的对象。
- 缺点：
- 工厂类的职责过重，一旦工厂类出现问题，会影响到整个对象的创建过程。
- 增加了代码的复杂性，特别是在有多种创建条件和对象类型的情况下。
- 使用案例：在一些组件库中，根据用户传入的不同参数（如组件的类型、样式等），通过工厂函数来创建对应的组件实例。
- 发布 - 订阅模式
- 原理：类似于观察者模式，但加入了一个中间的消息中心。发布者发布消息到消息中心，订阅者从消息中心订阅消息，当有相应消息发布时，订阅者会收到通知。
- 优点：
- 解耦了发布者和订阅者，双方不需要知道对方的存在，只要关注消息中心即可。
- 可以灵活地添加或删除订阅者，方便扩展功能。
- 缺点：
- 消息中心的实现可能比较复杂，需要考虑消息的存储、传递的效率等问题。
- 过度依赖消息中心，若消息中心出现故障，整个系统的消息传递都会受到影响。
- 使用案例：在一些大型的前端应用中，用于组件之间的通信。比如一个事件总线，不同的组件可以发布和订阅事件，实现跨组件的数据传递和交互。
