You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
importControllerfrom"../../controller";importOrderServicefrom"./order-service";// A 页面constorderService=Controller.getInstance().getService(OrderService);constpriceService=Controller.getInstance().getService(PriceService);// B 页面都会使用同一个服务constorderService=Controller.getInstance().getService(OrderService);
在实际的项目中,程序由许多对象组成,对象间的交流错综复杂。
随着应用程序的规模增大,对象越来愈多,他们之间的关系也越来复杂。对象间很容易出现相互引用而导致程序无法运行。同时开发者需要改变或者删除某一个对象时候,需要查找并且改造所有引用到它的对象。这样一来,改造的成本会变的非常高。
但中介者模式可以让各个对象之间得以解耦。
之前的场景下,如果 A 发生了改变,开发者需要修改 B、D、E、F 4 个对象,而通过中介者模式,我们只需要修改中介者这一个对象即可。
中介者的好处是简化了对象之间的交互,坏处则是中介类有可能会变成大而复杂的“上帝类”(God Class)。所以,在使用中介者模式时候,设计上一定要非常克制。
实际使用
在前端项目开发的过程中,有很多业务无关的功能,但这些功能会散落在各个业务中,难以管理,我们利用中介者模式的思想来构建一个的控制器。
基础控制器
此时控制器中有一个极简的缓存 tmpCache,发布订阅工具。以及服务端请求方法 api。开发者只需要导入 Controller 类即可使用。如果后续需要更加复杂的缓存或者改造 api(如切换为 fetch)请求方法。开发者可以很快的进行替换。而无需改造对应文件。
添加用户类
登录的用户信息以及对应操作可以说是对象交互的核心,将其放入控制器中。
此时控制器已经具备前端开发中“大部分”功能了,如数据缓存,数据请求,登录用户信息处理等。大部分情况下,中介类也基本够用了。至于其他的工具类,除非 80% 的业务都会用到,否则不建议添加到此类中去。但对于这些工具做一层简单的封装也是必要的(考虑后续成本)。
添加业务类
此时控制器有了用户信息,多种缓存,请求方法等。我们可以通过注入来实现其他业务。
开发者可以在具体的代码中这样使用。
有同学可能会奇怪,为什么 Controller 不能直接导入或者自动注入 OrderService 呢。这样使用的原因是往往 Controller 和 BasicService 在基础类中,具体的业务类分布在各个业务代码中。
这里没有使用任何依赖注入的框架,原因是因为如果引入了依赖注入会大大增加复杂度。同时前端的业务都是分散的,没有必要都放在一起。在组件需要使用到服务候才将其装载起来。
The text was updated successfully, but these errors were encountered: