zouyu
设计模式know

设计模式

# 1. 什么是 MVVM？比之 MVC 有什么区别？什么又是 MVP ？

# 1.1. MVVM 模式

MVVM（Model-View-ViewModel）是一种架构模式，主要用于构建用户界面。它将应用程序分为三个主要组件：

  • Model（模型）：负责管理应用程序的数据和业务逻辑。
  • View（视图）：负责用户界面的展示，通常由用户直接看到的内容组成。
  • ViewModel（视图模型）：作为模型和视图之间的桥梁，负责处理视图显示所需的数据准备逻辑，并将视图的事件映射到模型的操作。

MVVM 的一个关键特性是数据绑定，即视图与视图模型之间的自动同步。这种同步使得开发者可以专注于数据和业务逻辑，而无需手动更新视图。

# 1.2. MVVM 与 MVC 的区别

MVC（Model-View-Controller）也是一种经典的架构模式，但它与 MVVM 存在一些关键区别：

  • Controller（控制器）：在 MVC 中，控制器负责处理用户输入，并更新模型和视图。而在 MVVM 中，视图模型（ViewModel）承担了类似控制器的部分责任，但视图模型的主要职责是为视图准备数据，而不是直接处理用户输入。
  • 数据绑定：MVVM 强调数据绑定，视图和视图模型之间的数据可以自动同步。MVC 中的数据传递通常是单向的，从控制器到视图，视图无法直接与模型交互。
  • 职责分离：MVVM 更加强调视图的职责，视图不必了解业务逻辑，只负责显示数据。而 MVC 中，视图可以包含一些简单的展示逻辑，但通常需要控制器来协调视图和模型之间的交互。
  • MVVM 模式中的 VM，指的是 ViewModel，它和 MVP 的思想其实是相同的，不过它通过双向的数据绑定，将 View 和 Model 的同步更新给自动化了。当 Model 发生变化的时候，ViewModel 就会自动更新；ViewModel 变化了，View 也会更新。这样就将 Presenter 中的工作给自动化了。我了解过一点双向数据绑定的原理，比如 vue 是通过使用数据劫持和发布订阅者模式来实现的这一功 能。

# 1.3. MVP 模式

MVP（Model-View-Presenter）也是一种架构模式，主要用于开发复杂的用户界面。它由以下三个主要组件构成：

  • Model（模型）：负责管理应用程序的数据和业务逻辑，与 MVVM 中的模型相同。
  • View（视图）：负责用户界面的展示，通常由用户直接看到的内容组成，与 MVVM 中的视图相同。但在 MVP 中，视图相对被动，它不具备任何业务逻辑，仅负责展示。
  • Presenter（表现层）：作为视图和模型之间的桥梁，负责处理用户输入，更新模型，并将视图的展示逻辑与模型的操作隔离。它类似于 MVVM 中的视图模型，但职责更为明确，表现层只负责将数据从模型传递到视图，或者将用户操作传递给模型。

# 1.4. 总结

  • MVVM 强调数据绑定和视图的自动更新，适合需要高数据同步和用户交互的场景。
  • MVC 通过控制器协调视图和模型，适合需要清晰职责分离和展示逻辑的场景。
  • MVP 将视图逻辑完全移到表现层，视图只负责展示，适合需要复杂用户交互且需要清晰职责分离的场景。

# 2. 设计模式分类

  • 创建型模式：用于描述如何创建对象，包括 1.工厂方法模式、2.抽象工厂模式、3.单例模式、4.建造者模式、5.原型模式。
  • 结构型模式，共七种：1.适配器模式、2.装饰器模式、3.代理模式、4.外观模式、5.桥接模式、6.组合模式、7.享元模式。
  • 行为型模式，共十一种： 1.策略模式、2.模板方法模式、3.观察者模式、4.迭代子模式、5.责任链模式、6.命令模式、7.备忘录模式、8.状态模式、9.访问者模式、10.中介者模式、11.解释器模式。

# 3. 设计模式的六大原则

  1. 开闭原则：一个软件实体应当对扩展开放，对修改关闭。
  2. 单一职责原则：一个类只负责一项职责，其逻辑应该简单而直接。
  3. 依赖倒置原则：高层模块不应该依赖低层模块，二者都应该依赖抽象。
  4. 接口隔离原则：使用多个专门的接口，而不使用单一的总接口。
  5. 迪米特法则：一个对象应该对其他对象保持最少的了解。简称类间解耦
  6. 组合/聚合复用原则：尽量使用组合/聚合关系而不是继承关系来达到代码复用的目的。

# 4. 单例模式

保证一个类只有一个实例，并且提供一个访问该全局访问点

# 4.1. 那些地方用到了单例模式?

  1. 网站的计数器，一般也是采用单例模式实现，否则难以同步。
  2. 应用程序的日志应用，一般都是单例模式实现，只有一个实例去操作才好，否则内容不好追加显示。
  3. 多线程的线程池的设计一般也是采用单例模式，因为线程池要方便对池中的线程进行控制
  4. Windows 的（任务管理器）就是很典型的单例模式，他不能打开俩个
  5. windows 的（回收站）也是典型的单例应用。在整个系统运行过程中，回收站只维护一个实例。

# 4.2. 单例模式的优点

  1. 节省内存，避免频繁的创建销毁对象，降低系统开销。
  2. 避免对共享资源的多重占用，可以避免一些线程安全问题。
  3. 单例模式可以方便地全局访问，优化和共享资源。

# 4.3. 单例模式的缺点

  1. 单例模式一般没有接口，扩展比较困难,不适用于变化的对象。
  2. 单例模式违反了依赖倒置原则，如果要改动实现，则涉及到修改全局变量，破坏了系统的封装性。
  3. 单例模式在多线程环境下需要加锁，效率会受到影响。

# 5. 工厂模式

将对象的创建逻辑与使用逻辑分离，由专门的 “工厂类” 负责对象实例化，从而降低代码耦合度、提高可扩展性和可维护性。

# 5.1. 工厂模式好处

  1. 工厂模式是我们最常用的实例化对象模式了，是用工厂方法代替 new 操作的一种模式。
  2. 利用工厂模式可以降低程序的耦合性，为后期的维护修改提供了很大的便利。
  3. 将选择实现类、创建对象统一管理和控制。从而将调用者跟我们的实现类解耦。

# 5.2. 工厂模式缺点：

  1. 类数量膨胀：每新增一个产品，需同时新增一个工厂类，导致系统中类的数量翻倍。
  2. 调用复杂度提高：调用者需知道 “产品对应哪个工厂”（如创建 BMW 需使用 BMWFactory），而非简单传递参数。

# 6. 观察者模式和发布订阅模式分别是什么？有什么区别？

观察者模式：一个对象（观察者）订阅另一个对象（主题），当主题被激活的时候，触发观察者里面的事件。 发布订阅模式：订阅者把自己想要订阅的事件注册到调度中心，当发布者发布事件到调度中心（就是该事件被触发），再由调度中心统一调度订阅者注册到调度中心的处理代码。

###发布订阅模式应用场景：

  1. 全局事件总线
  2. Redux/Vuex 状态管理
  3. WebSocket 消息处理
  4. 微前端通信
  5. DOM 事件系统
document.addEventListener('click', handler) // 订阅
element.dispatchEvent(new Event('click')) // 发布
特性 观察者模式 发布订阅模式
耦合度 较高（直接引用） 较低（通过中间件）
灵活性 较低 较高
实现复杂度 简单 相对复杂
典型应用 Vue 响应式、表单验证 事件总线、状态管理
性能影响 直接调用，性能较好 需要查找订阅者，稍慢
上次更新: