50 lines
2.5 KiB
Markdown
50 lines
2.5 KiB
Markdown
|
# 中介者模式
|
|||
|
|
|
|||
|
|
## 定义
|
|||
|
|
|
|||
|
|
> wiki: 中介者模式（Mediator Pattern）是用来降低多个对象和类之间的通信复杂性。这种模式提供了一个中介类，该类通常处理不同类之间的通信，并支持松耦合，使代码易于维护。中介者模式属于行为型模式。
|
|||
|
|
|
|||
|
|
这个名字十分贴切了，跟现实中的中介很像...，比如一个租房的黑中介，所有租客只需要直接与中介通信即可，所有房主也是直接与中介通信即可，省去了自己找租客的麻烦，
|
|||
|
|
|
|||
|
|
但是通过中介，总是要有一些代价的，在现实生活中是高昂的中介费...在代码中就是需要维护中介对象...
|
|||
|
|
|
|||
|
|
具体的结构可以想象为由客户端与客户端直连的网状结构，变为了由一个服务器进行转发的星型结构。
|
|||
|
|
|
|||
|
|
## 类图
|
|||
|
|
|
|||
|
|
|
|||
|
|
(图源网络)
|
|||
|
|
|
|||
|
|
从类图中可以看出，两个具体结构体并没有直接进行通信，而是通过一个具体中介者来通信的
|
|||
|
|
|
|||
|
|
## 角色
|
|||
|
|
|
|||
|
|
- 抽象中介者
|
|||
|
|
|
|||
|
|
- 具体中介者
|
|||
|
|
|
|||
|
|
- 抽象客户端
|
|||
|
|
|
|||
|
|
- 具体客户端
|
|||
|
|
|
|||
|
|
## 举个栗子
|
|||
|
|
|
|||
|
|
我觉得简单的例子并不能说明中介者的好处，因为对于只有一个两个的客户，使用中介者本身就不是好的设计，中介者模式是用在大量对象的松散耦合上的，类比路由器...
|
|||
|
|
|
|||
|
|
所以这里直接举一个实际应用的例子: `MVC`!
|
|||
|
|
|
|||
|
|
`MVC` 结构是一个典型的中介者模式，`C`(控制器) 就是 `M`(模型) 与 `V`(视图) 之间的中介者
|
|||
|
|
|
|||
|
|
> 多说一句题外话，现在的 MVC 模式并不够抽象，控制器的功能应该仅仅包含处理URL，而真正的逻辑应该放在 Services(服务) 中去处理,现在的很多项目都没有 Services,其中一个原因就是项目体量太小，很多人为了简便，便将业务逻辑直接写入了控制器中。
|
|||
|
|
|
|||
|
|
而具体的实现代码: 我在之前写过一篇 [使用Go写一个简易的MVC的Web框架](https://juejin.im/post/5b7240aaf265da282809f11e) ，里面完成了一个 `web` 服务器，在控制器中沟通数据库并打印网页，就完成了一个完整的 `MVC` 结构。
|
|||
|
|
|
|||
|
|
当然这个框架是我第一版写的了... 现在的代码基本上全部重写了...
|
|||
|
|
|
|||
|
|
## 小结
|
|||
|
|
|
|||
|
|
- 优点: 降低了类之间的耦合，从而降低了项目的复杂度
|
|||
|
|
|
|||
|
|
- 缺点: 随着项目的变大，中介者会变得越来越大，越来越复杂，对中介者的解耦也变得越来越必要。
|
|||
|
|
|