设计模式调研与思考

自勉：学习设计模式不仅学习其设计思想也要不局限于代码层面去理解。多去想实际生活中的场景，能更好的理解，达到更好应用的效果。多看代码设计，多从实践中应用设计模式。

1. 监听模式

1. 概况总结

给一个东西做监督，把相应结果通知观察者

1. 实际生活中思考便于理解

• 智能电饭煲：可以定时焖饭，下班回来就能吃到香喷喷的大米饭，不用一直守着电饭煲。

• 饮水机烧水:定时烧到什么温度，烧好了报警，人直接可以喝，不用盯着他烧。

1. 设计模式的应用场景思考

• 被观察对象只需通知观察对象结果不需要告知其细节。如消息推送。

• 一个对象的更新需要依赖于另一个对象的更新，或者对一个对象状态或数据的更新，需要其他对象同步更新 。

1. 该设计模式的注意点

• 明确谁是观察者，谁是被观察者，一般一个被观察对象可以有多个观察对象。

• 被观察者无需指定具体的观察者，观察者可以自己决定是否调用哪个被观察者的通知。

• 被观察者至少需要三个方法:添加监听者，移除监听者，通知监听者到方法，观察者至少有一个方法:更新方法，更新当前的内容，做出相应的处理。

1. 在项目中应用的小想法（待实际考量）

有一个想法在任务进度监控，任务有效期监控，都可以思考在其中进行应用该模式，达到只关心任务的结果，可以将这个模式复用到其他的项目中。具体设计，后期做深入思考。

在项目中可以应用它做一些监控这个任务什么时候执行完，或者是出现问题，做一个像排行榜一样的，开发人员就是观察者去查看，不用一直盯着跑的程序。

1. 优缺点的思考

该设计模式应用起来复杂，观察者与被观察者之间关系比较复杂，而且执行过程当中相对来说是串联的，如果某个观察者出现了问题，会影响其他整体的效率。所以考虑效率采用异步的方式。

1. 职责模式

1. 概况总结

像责任链条一级到一级，每个人有每个人的责任，互不关心，互不影响，需求人只需要去提需求，不需要知道处理者和具体处理方法。

1. 实际生活中思考便于理解

• 外卖点餐:用户只需下单想要的菜品，他不需要知道菜品是由饭店的菜品选购人员去哪里选购，采购给厨师，厨师做菜，再由外卖小哥配送，最后到达用户嘴里。

• 员工申请kk:员工申请资产或者归还资产等，由上级领导到上上级领导，再到资产负责人，然后层层审批到达员工。

1. 设计模式的应用场景思考

• 请求的处理方式需要有明显的层层递进，传递关系。

• 可以是多个对象对同一个请求进行处理。具体是到哪个对象处理可以由运行时刻自动确定。

• 请求在被处理的过程中需要程序运行时动态确定。

• 每个责任人都有各自的职责，互不影响，互不关注。

1. 该设计模式的注意点

• 需要明确请求者和请求内容。谁是发送请求方，及他们具体相应的调用关系。

• 有哪些责任人，并对责任人进行抽象，每个责任人有其各自的特点，但都可以完成处理请求这一方法，所以需要对责任人进行抽象。使他们的责任可以传递。

• 责任链上的责任人可以根据具体的业务需要进行排列组合。

1. 在项目中应用的小想法（待实际考量）

文件在下发过程中经过了筛选，过滤，排查有无敏感词，等等每一个需要都是每一个职责，某个文件需要不同的职责人去动态处理请求，用户只关心最后文件的可靠性或得到该文件不需要关注文件是怎么被一系列操作的过程。

1. 优缺点的思考

• 优点:

降低了合度，将请求的发送者和接收者进行解耦。而且多个对象都可以接受请求。

对象可规定调用不同职责的人来执行，增强了灵活性。也可以更改责任链中不同成员的调用次序，并动态的增加或删除责任人。

简化了对象，可以使对象不需要知道整个链路的结构及解决者是哪个责任人。

• 缺点:

并能确保请求一定被接收

可能系统性能受到一定影响，在调用代码执行时不太方便。容易出现循环调用。

1. 装饰模式

1. 概况总结

给某个方法丰富功能，让他在不改变本身前提下拥有另一个方法的能力。而且该能力最好是通用的。

1. 实际生活中思考便于理解

穿衣打扮:不同的人去不同的地方会穿不同的颜色的衣服，裤子，鞋。

1. 设计模式的应用场景思考

• 可以动态增加或删除某些功能

• 类定义被隐藏或类定义不能用于生成子类

• 对这个类有大量的扩展功能的子类，并且这个需求的类有很多。

1. 该设计模式的注意点

• 对于类的装饰的顺序不同可能会产生不一样的效果。注意装饰的顺序。

• 把每一个要装饰的功能放在单独函数里

1. 在项目中应用的小想法（待实际考量）

在结果回收模块当中，由于很多字段在接入过程当中格式错误导致程序崩溃，想在做业务操作之前对数据格式进行校验，在结果回收框架设计当中增加了装饰模式实现了错误字段一个过滤器操作。

1. 优缺点的思考

• 优点:

可以动态的给对象添加更多的功能

使用装饰器来增加功能，比继承更加灵活，可以在不创建子类的情况下，增加更多扩展功能。

可以根据不同的需要增加不同装饰器，不同顺序的调用装饰器也会产生不同的结果。

装饰类和被装饰类形成解耦。

• 缺点：

在装饰方法排错过程当中更加困难，对多个装饰器的不同调用顺序也会造成不同结果。需要按顺序逐层排查比较繁琐。

1. 代理模式

1. 概况总结

不能直接调用另一个方法，借助另一个方法调用即可完成。

1. 实际生活中思考便于理解

代收货:快递由门口保安代收，放到快递架上。

代看顾宠物:出门了，宠物没法照顾，代理看顾宠物人员来帮忙。

银行支票:代替现金，并可以控制人员资金

1. 设计模式的应用场景思考

不想或者不能直接调用另一个对象时，需要借助另一个对象调用该对象。

各种特殊用途的代理，比如远程代理，防火墙代理，同步话代理...

1. 该设计模式的注意点

有三个要素，操作或者任务的接口类，真正完成操作或者任务的具体类，代替真实主人完成操作或任务的代理类。

1. 在项目中应用的小想法（待实际考量）

• 想法在日志监控明皓哥log那个设计成代理模式，与业务解耦

• 还可以在设备监控那里使用代理模式

1. 优缺点的思考

• 优点:

一定程度上降低了系统的耦合度，可以调节调用者和被调用者之间的协调性

增加了额外的功能，并且可以隐藏被代理的内部功能

• 缺点：

增加了一个处理对象，在性能上面可能会造成速度变慢

代理模式的实现功能可能比较复杂。需要额外的工作量

1. 中介模式

1. 概况总结

两个可能互不认识的对象，需要一个中间对象帮忙完成这两个对象的交易。

1. 实际生活中思考便于理解

房屋中介:用户和房屋中介完成交易，房屋中介跟房源房主进行交易。

1. 设计模式的应用场景思考

• 两者需要有复杂的方式通信，需要借助第三方， 且两者互相依赖关系比较混乱，难以理解

• 想用中间类来实现多个类的行为，不想生成太多的子类。

• 很多对象都与这一个对象通信，并且这一个对象引用很多对象，导致难以复用这个对象

1. 该设计模式的注意点

• 多个类相互耦合形成网状结构时要要中介者进行解耦。

• 注意中介者的设计不要过于复杂，因为它的影响面广。

1. 在项目中应用的小想法（待实际考量）

海量清洗缓存服务，缓冲服务做中介，连接各种原数据，及数据存储数据库。

1. 优缺点的思考

• 优点:

减少了对象之间的交互过程，使他提成了多个对象间的行为。

将多个调用者和多个实现者之间的多对多的关系转化成一对多的关系。更加容易维护。

• 缺点：

中介类可能会变得越来越庞大且复杂，难以维护，因为大多的逻辑内容都需要中介去承受。

中介类出问题会导致两分多个使用者被影响

1. 适配模式

1. 概况总结

将原来的接口，转换成适配相应功能的新接口，解决由于接口不兼容而不能一起工作的那些类

1. 实际生活中思考便于理解

音频播放器：只能播放mp3，经过更新成高级的音乐播放器可以播放MP4

1. 设计模式的应用场景思考

需要使用的类先不满足需要

对已有的系统做更新，特别是在设计好的框架之中使用第三方工具时候比较合适

1. 该设计模式的注意点

• 系统过多使用适配器很难维护。明明调A接口实现的是B就不好了

• 适合运行时使用的突变需求比较方便。一般不在详细设计时使用。

• 区分好 目标 源对象 适配器这三个角色

1. 在项目中应用的小想法（待实际考量）

项目中前端应用新文档功能或者现有功能，更新该接口进行适配实现

1. 优缺点的思考

• 优点:

增强了复用功能，

让两个无关联的类，适配运行

灵活性好，不影响本类

• 缺点：

如 Target 不是抽象类或接口，而一个实体类，就很难实现

过多使用，会比较难维护。明明调A接口实现的是B就不好了

1. 简单工厂模式

1. 概况总结

共同的父类，根据不同参数，创建不同类的实例

1. 实际生活中思考便于理解

榨汁机：可以放苹果出来就是苹果汁，放橙子出来就是橙汁

1. 设计模式的应用场景思考

• 产品类型不多且具有明显的继承关系时。

• 使用者不关心具体的类型，只希望传入合适的参数能返回合适的对象，并且该很多产品具有相同的方法和类似的属性。

• 解决很多ifelse语句，

1. 拓展应用

当工厂生产的所有产品每个都只能有一个对象时：比如

1. 该设计模式的注意点

• 存在明显继承性，且不宜过多

• 使用人只需关注抽象类的方法，不用对具体类型向下转型，因为所有产品都有相同方法和功能。

1. 在项目中应用的小想法（待实际考量）

创建任务是一个工厂，通过传入病毒漏洞等参数，实现创建相应检测任务。

1. 代码优化想法

举例商店以不同方式回馈客户，有优惠劵，赠送会员，赠送商品等方式。

普通写法：if (为优惠券)：

   。。。。。

   elif（赠送会员）：

     。。。。。

工厂方法优化：

创建一个抽象的优惠方式类，优惠劵，赠送会员，赠送商品等继承并重写赠送的东西方法。

创建一个生产优惠给客户的类，if（x == 优惠券）：创建优惠券对象。。。。

1. 优缺点的思考

• 优点:

简单

只关注传入参数就可以创建该对象，不需要关注具体对象的类名称。

抽象专门的类创建其他，只要传入适当的参数即可。

• 缺点：

不易拓展，一旦添加新的产品类型，就不得不修改工厂的创建逻辑。

产品类型较多时，工厂的创建逻辑可能过于复杂，createProduct 方法会变得非常庞大，switch … case …（或 if … else …）的判断会变得非常多。

如果要增加或删除一个产品种类，就要修改 switch … case …（或 if … else …）的判断代码，不符合开放—封闭原则。

1. 工厂方法模式

1. 概况总结

为解决简单工厂模式中不符合开放-封闭原则的问题，将工厂拆分出抽象工厂父类，并增加多个子类分别负责创建不同的具体产品。

1. 优缺点的思考

• 优点:

解决了简单工厂模式中不符合 开放—封闭原则 的问题，使程序更容易拓展。

• 缺点：

对于有多种分类的产品，或具有二级分类的产品，工厂方法模式并不适用。

1. 抽象工厂模式

1. 概况总结

用来解决工厂方法不适用有二级分类的创建

1. 优缺点的思考

• 优点:

解决工厂方法不适用有二级分类的创建

• 缺点：

二级以上的分类会造成很臃肿

不能解决多种分类的问题和多种组合的问题

1. 迭代模式

1. 概况总结

遍历元素并找下一个元素，不用关系该元素的实现细节。可以从前向后遍历也可以从后向前遍历。

1. 实际生活中思考便于理解

银行办理业务：叫号一个一个办理

医院就诊：叫号一个一个就诊

1. 设计模式的应用场景思考

• 统一的功能实现接口，其他集合都可以访问这个接口实现相同功能

• 集合内部的设计比较复杂，想隐藏其细节，只提供对外访问方式

• 可以对一系列集合对象，执行不同遍历方式

1. 该设计模式的注意点

• 获取迭代器的值不是通过取地址，而是根据迭代器的成员，它的成员提供了返回迭代器的功能，例如，begin、end；

• 如果迭代器为空，那么begin、end返回的都是指向容器尾部元素的下一个元素

1. 在项目中应用的小想法（待实际考量）

领取任务模块，执行完一个任务申领下一个任务，遍历任务列表时可以考虑一下这个模式

1. 优缺点的思考

• 优点:

    可以将存储和遍历分开，解耦

    简化了聚合数据的访问方式，都统一了

    可以有多种遍历方式，可以从前向后遍历也可以从后向前遍历

• 缺点：

增加新的聚合函数时可能得增加新的迭代器

1. 组合模式

1. 概况总结

将部分组合成整体的模式

1. 实际生活中思考便于理解

汽车组装、电脑组装、公司和各个部门

1. 设计模式的应用场景思考

• 具有一定的层次关系，部分和整体的关系时

• 部分中的对象有相似的行为，想统一使用这些对象时

1. 该设计模式的注意点

用户只需操作整体，不需管部分内部及直接的关系

1. 在项目中应用的小想法（待实际考量）

暂时还没想到

1. 优缺点的思考

• 优点:

调用方便，可以像调用一般对象一样

灵活性高，可以不同组合部分对象成不同整体，做相应操作

• 缺点：

当层级过于复杂，层级过于深，组成的整体比较庞大