转发这位大佬博客：https://www.cnblogs.com/IcanFixIt/p/7518146.html
| 名称 | 优点 | 缺点 |
|---|---|---|
| 分层模式 | 一个较低的层可以被不同的层所使用。层使标准化更容易，因为我们可以清楚地定义级别。可以在层内进行更改，而不会影响其他层。 | 不是普遍适用的。在某些情况下，某些层可能会被跳过。 |
| 客户端-服务器模式 | 很好地建立一组服务，用户可以请求他们的服务。 | 请求通常在服务器上的单独线程中处理。由于不同的客户端具有不同的表示，进程间通信会导致额外开销。 |
| 主从设备模式 | 准确性——将服务的执行委托给不同的从设备，具有不同的实现。 | 从设备是孤立的：没有共享的状态。主-从通信中的延迟可能是一个问题，例如在实时系统中。这种模式只能应用于可以分解的问题。 |
| 管道-过滤器模式 | 展示并发处理。当输入和输出由流组成时，过滤器在接收数据时开始计算。轻松添加过滤器，系统可以轻松扩展。过滤器可重复使用。 可以通过重新组合一组给定的过滤器来构建不同的管道。 | 效率受到最慢的过滤过程的限制。从一个过滤器移动到另一个过滤器时的数据转换开销。 |
| 代理模式 | 允许动态更改、添加、删除和重新定位对象，这使开发人员的发布变得透明。 | 要求对服务描述进行标准化。 |
| 点对点模式 | 支持分散式计算。对任何给定节点的故障处理具有强大的健壮性。在资源和计算能力方面具有很高的可扩展性。 | 服务质量没有保证，因为节点是自愿合作的。安全是很难得到保证的。性能取决于节点的数量。 |
| 事件总线模式 | 新的发布者、订阅者和连接可以很容易地添加。对高度分布式的应用程序有效。 | 可伸缩性可能是一个问题，因为所有消息都是通过同一事件总线进行的。 |
| 模型-视图-控制器模式 | 可以轻松地拥有同一个模型的多个视图，这些视图可以在运行时连接和断开。 | 增加复杂性。可能导致许多不必要的用户操作更新。 |
| 黑板模式 | 很容易添加新的应用程序。扩展数据空间的结构很简单。 | 修改数据空间的结构非常困难，因为所有应用程序都受到了影响。可能需要同步和访问控制。 |
| 解释器模式 | 高度动态的行为是可行的。对终端用户编程性提供好处。提高灵活性，因为替换一个解释程序很容易。 | 由于解释语言通常比编译后的语言慢，因此性能可能是一个问题。 |
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！