▐ 模式定义
▐ 适用场景
适用于多节点的流程处理，每个节点完成各自负责的部分，节点之间不知道彼此的存在，比如 OA 的审批流，Java Web 开发中的 Filter 机制。
多个对象可以处理同一个请求，但具体由哪个对象处理则在运行时动态决定。
在请求处理者不明确的情况下向对个对象中的一个提交一个请求。
需要动态处理一组对象处理请求。
举一个生活中的例子，比如你突然想世界那么大你想去看看，但是处于现实的你还不能丢了工作，得到请假的OA申请，请假天数如果是半天到1天，可能直接主管批准即可；如果是1到3天的假期，需要部门经理批准；如果是3天到30天，则需要总经理审批；大于30天，正常不会批准。这种简单的流程即可试用于我们当前业务场景。
▐ 实践经验
业务流程很简单：
打电话注销信用卡
工作人员注销信用卡
注销信用卡有个背景是这样的，如果信用卡存在账单未还清，存在溢出款，存在特殊年费未使用等情况是不允许注销信用卡的，鉴于此，我们在注销之前加了一套是否允许注销的检验逻辑。
大体如下：
是否存在账单未还清，比如有已出账单未还清，有未出账单未还清，有年费管理费等未还清等。
是否存在溢出款多余的钱。
是否存在高额积分未使用，需用户确认放弃积分等。
针对这几类情况建立了三类过滤器，分别是：
UserLogoutUnpaidBillsLimitFilter：是否存在未还清金额。
UserLogoutOverflowLimitFilter：是否存在溢出款。
UserLogoutGiveUpPointsLimitFilter：是否放弃高额金额。
判断逻辑是先通过UserLogoutUnpaidBillsLimitFilter判断当前用户是否可以注销信用卡。如果允许继续由 UserLogoutOverflowLimitFilter 判断是否存在溢出款，是否可以注销信用卡；如果没有溢出款继续由UserLogoutGiveUpPointsLimitFilter 判断当前用户是否存在高额积分，前面三条判断，只要有一个不满足就提前返回。
总结：将每种限制条件的判断逻辑封装到了具体的 Filter 中，如果某种限制条件的逻辑有修改不会影响其他条件，如果需要新加限制条件只需要重新构造一个 Filter 织入到 FilterChain 上即可。
责任链中一个处理者对象，其中只有两个行为，一是处理请求，二是将请求转送给下一个节点，不允许某个处理者对象在处理了请求后又将请求转送给上一个节点的情况。对于一条责任链来说，一个请求最终只有两种情况，一是被某个处理对象所处理，另一个是所有对象均未对其处理，前一种情况称该责任链为纯的责任链，对于后一种情况称为不纯的责任链，实际应用中，多为不纯的责任链。
策略设计模式
▐ 模式定义
策略这个词应该怎么理解，打个比方说，我们出门的时候会选择不同的出行方式，比如骑自行车、坐公交、坐火车、坐飞机等等，这些出行方式，每一种都是一个策略。
再比如我们去逛商场，商场现在正在搞活动，有打折的、有满减的、有返利的等等，其实不管商场如何进行促销，说到底都是一些算法，这些算法本身只是一种策略，并且这些算法是随时都可能互相替换的，比如针对同一件商品，今天打八折、明天满100减30，这些策略间是可以互换的。
策略模式（Strategy Pattern）是定义了一组算法，将每个算法都封装起来，并且使它们之间可以互换。
▐ 适用场景
主要是为了消除大量的 if else 代码，将每种判断背后的算法逻辑提取到具体的策略对象中，当算法逻辑修改时对使用者无感知，只需要修改策略对象内部逻辑即可。这类策略对象一般都实现了某个共同的接口，可以达到互换的目的。
多个类只有算法或行为上稍有不同的场景
算法需要自由切换的场景
需要屏蔽算法规则的场景
▐ 实践经验
业务流程很简单：
挑选商品
选择不同的优惠方式结账
比如即将到来的双十一活动某些线下商家举办活动，折扣力度如下满300-80，部分商品5折，根据不同会员等级享受不同的折扣最低7折，周年庆活动可享8折等等。假如这些活动折扣不可同享，那么如何去实现以及考虑可扩展性的话策略模式是一种不错的选择。
模板设计模式
▐ 模式定义
模板的价值就在于骨架的定义，骨架内部将问题处理的流程已经定义好，通用的处理逻辑一般由父类实现，个性化的处理逻辑由子类实现。
比如炒土豆丝和炒麻婆豆腐，大体逻辑都是：
1、切菜
2、放油
3、炒菜
4、出锅
1，2，4 都差不多，但是第 3 步是不一样的，炒土豆丝得拿铲子翻炒，但是炒麻婆豆腐得拿勺子轻推，否则豆腐会烂。
▐ 使用场景
不同场景的处理流程，部分逻辑是通用的，可以放到父类中作为通用实现，部分逻辑是个性化的，需要子类去个性实现。
模板模式（Template Pattern）中，一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。这种类型的设计模式属于行为型模式。
▐ 实践经验
还是接着之前商品折扣的例子来说，后期我们新加了两个需求：
用户享受不同折扣增加 trace。
用户享受折扣后是否升级会员等级。
所以现在的流程变成了这样：
1、trace 开始。
2、计算用户不同折扣力度。
3、是否允许升级会员等级，如果允许执行升级会员等级逻辑。
4、trace 结束。
其中 1 和 4 是通用的，2 和 3 是个性化的，鉴于此可以在折扣策略之前增加了一层父类的策略，将通用逻辑放到了父类中。
修改后的代码如下：
观察者设计模式
▐ 模式定义
拍卖的时候，拍卖师观察最高标价，然后通知给其他竞价者竞价 这种模式就可以使用观察者模式。顾名思义，此模式需要有观察者（Observer）和被观察者（Observable）两类角色。当 Observable 状态变化时会通知 Observer，Observer 一般会实现一类通用的接口。
比如 java.util.Observer，Observable 需要通知 Observer 时，逐个调用 Observer 的 update 方法即可，Observer 的处理成功与否不应该影响 Observable 的流程。
▐ 使用场景
当对象间存在一对多关系时，则使用观察者模式（Observer Pattern）。比如，当一个对象被修改时，则会自动通知依赖它的对象。观察者模式属于行为型模式。
一个对象（Observable）状态改变需要通知其他对象，Observer 的存在不影响 Observable 的处理结果，Observer 的增删对 Observable 无感知。
比如 Kafka 的消息订阅，Producer 发送一条消息到 Topic，至于是 1 个还是 10 个 Consumer 订阅这个 Topic，Producer 是不需要关注的。
▐ 实践经验
在责任链设计模式那块我通过三个 Filter 解决了注销信用卡限制检验的问题，其中有一个 Filter 是用来检验用户积分的，我这里只是读取用户的积分总额和次数，那么消费次数获得积分的累加是怎么完成的呢？
其实累加这块就用到了观察者模式，具体来讲是这样，当交易系统收到支付成功回调时会通过 Spring 的事件机制发布“支付成功事件”。
这样负责积分消费次数累加和负责语音播报的订阅者就会收到“支付成功事件”，进而做各自的业务逻辑。
画个简单的图描述一下：
总结：观察者模式将被观察者和观察者之间做了解耦，观察者存在与否不会影响被观察者的现有逻辑。
装饰器设计模式
▐ 模式定义
装饰器模式（Decorator Pattern）允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。这种模式创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。
装饰器用来包装原有的类，在对使用者透明的情况下做功能的增强，比如 Java 中的 BufferedInputStream 可以对其包装的 InputStream 做增强，从而提供缓冲功能。
▐ 使用场景
在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。需要动态地给一个对象增加功能，这些功能也可以动态地被撤销。 当不能采用继承的方式对系统进行扩展或者继承。希望对原有类的功能做增强，但又不希望增加过多子类时，可以使用装饰器模式来达到同样的效果。
▐ 实践经验
有一个咖啡店，销售各种各样的咖啡，拿铁，卡布奇洛，蓝山咖啡等，在冲泡前，会询问顾客是否要加糖，加奶，加薄荷等。这样不同的咖啡配上不同的调料就会卖出不同的价格。
总结：使用装饰器模式做了功能的增强，对使用者来说只需要做简单的组合就能继续使用原功能。装饰器模式充分展示了组合的灵活。利用它来实现扩展。它同时也是开闭原则的体现。如果相对某个类实现运行时功能动态的扩展。这个时候你就可以考虑使用装饰者模式！
桥接设计模式
▐ 模式定义
桥接模式是一种结构型设计模式， 可将一个大类或一系列紧密相关的类拆分为抽象和实现两个独立的层次结构， 从而能在开发时分别使用。
桥接（Bridge）是用于把抽象化与实现化解耦，使得二者可以独立变化。这种类型的设计模式属于结构型模式，它通过提供抽象化和实现化之间的桥接结构，来实现二者的解耦。
▐ 使用场景
如果一个系统需要在抽象类和具体类之间增加更多的灵活性，避免在两个层次之间建立静态的继承关系，通过桥接模式可以使它们在抽象层建立一个关联关系。
抽象部分和实现部分可以以继承的方式独立扩展而互不影响，在程序运行时可以动态的将一个抽象类子类的对象和一个实现类子类的对象进行组合，及系统需要对抽象类角色和实现类角色进行动态耦合。
一个类存在两个（或多个）独立变化的维度，且这两个（或多个）维度都需要独立进行扩展。
对于那些不希望使用继承或因为多层继承导致系统的个数急剧增加的系统，桥接模式尤为适用。
▐ 实践经验
性能管理系统中，数据产生后需要经过采集，汇聚，入库三个流程，用户才能查询使用。采集可以是snmp采集，也可以是ems采集；汇聚可以使storm汇聚，也可以是spark汇聚；入库可以是hdfs入库，也可以是mppdb入库。针对不同场景，我们可以灵活选择不同的采集，汇聚，入库方式。这种一个功能需要多种服务支持，每种服务又有不同类型的实现，使用桥接模式再适合不过。
桥接模式，顾名思义，就是把每种服务看做一座桥，我们可以根据实际场景选择不同的桥。上述例子表示数据产生到可以使用之前需要经过三座桥：采集桥->汇聚桥->入库桥。每座桥可以选择不同的构造。
总结：桥接模式可以将系统中稳定的部分和可扩展的部分解耦，使得系统更加容易扩展，且满足OCP原则，对调用者修改关闭。
✿ 拓展阅读
本文分享自微信公众号 - 淘系技术（AlibabaMTT）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。