网页设计支付场景 第1篇
代理模式就是提供一个代理对象来替换被访问的目标对象，但不改变被代理对象的业务能力，只是可以增加访问控制、打印日志等通用功能。
这个没有太多好说的，因为太常见。比如Spring的AOP，业务代码只需要管业务逻辑，而打印摘要日志（方法名、出入参、耗时等）、事务管理等使用切面搞定。还有rpc框架提供的远程代理，业务能力没有变，但加入了访问控制等能力。
示例：
less
代码解读
复制代码
public class GatewayServiceImpl implements GatewayService { @Override // 服务入口统一打印摘要日志 @DigestLog public GatewayResponse process(GatewayRequest request) { // 业务代码略 } }
网页设计支付场景 第2篇
外观模式简单理解就是设计接口，也就是所谓的接口与实现分离，客户端只需要知道接口定义，不需要知道具体实现。
像rpc框架一般都会定义一组接口，客户端只需要引用这些接口定义，由服务端进行具体实现。内部很多服务也基本是先设计接口，再实现服务。
最简单的示例如下：
定义接口：
csharp
代码解读
复制代码
public interface GatewayService { GatewayResponse process(GatewayRequest request); }
实现：
less
代码解读
复制代码
public class GatewayServiceImpl implements GatewayService { @Override @DigestLog public GatewayResponse process(GatewayRequest request) { // 业务代码略 } }
网页设计支付场景 第3篇
装饰器模式简单地说就是包装了原来的类，并扩展一些额外的业务能力。注意这些额外的业务能力和代理模式里面打印日志、权限管控等是不相同的，后者和业务无关。
最典型的例子就是Java IO操作相关的类。比如FileInputStream是一个基础的类，BufferedInputStream则包装了一个FileInputStream，然后额外提供缓冲读写的能力。
示例：
ini
代码解读
复制代码
// 使用装饰器增加缓冲功能 BufferedInputStream bis = new BufferedInputStream(FileInputStream(__));
网页设计支付场景 第4篇
状态模式可以简单理解为有限状态机的实现，就是把和状态相关的操作封装到一个独立的状态机类里面，而不是耦合在业务代码中。
支付系统里面有很多单据，每种单据都有自己的状态，比如支付单有“初始化”，“支付中”，“预授权成功”，“请款中”，“成功”，“失败”共6种状态，如果不使用状态模式，那就直接在订单类里面使用String来定义，状态的推进全部写if else或case when来实现，会导致这部分的代码很容易出错，要不就写得很复杂。
下面是一个典型的状态机设计：
从状态机设计图中可以看到，状态之间的变迁是通过事件来驱动的，比如INIT到PAYING，事件就是发起支付。
如果不使用状态机，示例：
javascript
代码解读
复制代码
if ((_PAYING_) { status = _SUCCESS_; } else if (...) { ... }
或者：
java
代码解读
复制代码
class OrderDomainService { public void notify(PaymentNotifyMessage message) { PaymentModel paymentModel = loadPaymentModel(()); // 直接设置状态 ((); // 其它业务处理 ... ... } }
或者：
ini
代码解读
复制代码
public void transition(Event event) { switch (currentState) { case INIT: if (event == ) { currentState = ; } else if (event == ) { currentState = ; } else if (event == ) { currentState = ; } break; // Add other case statements for different states and events } }
如果换成状态机模式，如下：
定义状态基类
csharp
代码解读
复制代码
/** * 状态基类 */ public interface BaseStatus { }
定义事件基类
csharp
代码解读
复制代码
/** * 事件基类 */ public interface BaseEvent { }
定义“状态-事件对”，指定的状态只能接受指定的事件
scala
代码解读
复制代码
/** * 状态事件对，指定的状态只能接受指定的事件 */ public class StatusEventPair { /** * 指定的状态 */ private final S status; /** * 可接受的事件 */ private final E event; public StatusEventPair(S status, E event) { = status; = event; } @Override public boolean equals(Object obj) { if (obj instanceof StatusEventPair) { StatusEventPair other = (StatusEventPair)obj; return () && (); } return false; } @Override public int hashCode() { // 这里使用的是google的guava包。 return (status, event); } }
定义状态机
scala
代码解读
复制代码
/** * 状态机 */ public class StateMachine { private final Map
定义支付的状态机。注：支付、退款等不同的业务状态机是独立的。
arduino
代码解读
复制代码
/** * 支付状态机 */ public enum PaymentStatus implements BaseStatus { INIT(_INIT_, _初始化_), PAYING(_PAYING_, _支付中_), PAID(_PAID_, _支付成功_), FAILED(_FAILED_, _支付失败_), ; // 支付状态机内容 private static final StateMachine
定义支付事件。注：支付、退款等不同业务的事件是不一样的。
arduino
代码解读
复制代码
/** * 支付事件 */ public enum PaymentEvent implements BaseEvent { // 支付创建 PAY_CREATE(_PAY_CREATE_, _支付创建_), // 支付中 PAY_PROCESS(_PAY_PROCESS_, _支付中_), // 支付成功 PAY_SUCCESS(_PAY_SUCCESS_, _支付成功_), // 支付失败 PAY_FAIL(_PAY_FAIL_, _支付失败_); /** * 事件 */ private String event; /** * 事件描述 */ private String description; PaymentEvent(String event, String description) { = event; = description; } }
在支付单模型中声明状态和根据事件推进状态的方法：
csharp
代码解读
复制代码
/** * 支付单模型 */ public class PaymentModel { /** * 其它所有字段省略 */ // 上次状态 private PaymentStatus lastStatus; // 当前状态 private PaymentStatus currentStatus; /** * 根据事件推进状态 */ public void transferStatusByEvent(PaymentEvent event) { // 根据当前状态和事件，去获取目标状态 PaymentStatus targetStatus = (currentStatus, event); // 如果目标状态不为空，说明是可以推进的 if (targetStatus != null) { lastStatus = currentStatus; currentStatus = targetStatus; } else { // 目标状态为空，说明是非法推进，进入异常处理，这里只是抛出去，由调用者去具体处理 throw new StateMachineException(currentStatus, event, _状态转换失败_); } } }
代码注释已经写得很清楚，其中StateMachineException是自定义，不想定义的话，直接使用RuntimeException也是可以的。
在支付业务代码中的使用：只需要((()))
php
代码解读
复制代码
/** * 支付领域域服务 */ public class PaymentDomainServiceImpl implements PaymentDomainService { /** * 支付结果通知 */ public void notify(PaymentNotifyMessage message) { PaymentModel paymentModel = loadPaymentModel(()); try { // 状态推进 ((())); savePaymentModel(paymentModel); // 其它业务处理 ... ... } catch (StateMachineException e) { // 异常处理 ... ... } catch (Exception e) { // 异常处理 ... ... } } }
好处：
定义了明确的状态、事件。
状态机的推进，只能通过“当前状态、事件、目标状态”来推进，不能通过if else 或case switch来直接写。比如：(INIT, , PAYING);
避免终态变更。比如线上碰到if else写状态机，渠道异步通知比同步返回还快，异步通知回来把订单更新为“PAIED”，然后同步返回的代码把单据重新推进到PAYING。
网页设计支付场景 第5篇
适配器用于两种不同类型的接口通过一个中间类做适配转换，以达到兼容的效果。
在支付系统中，后端一般都是提供RPC服务，但是客户端往往需要HTTP服务，这种情况下也需要适配器：把HTTP适配到RPC服务，或者说把HTTP服务转换成RPC服务。
在代码中最常见的就是Java IO类库里的字节流与字符流的处理。比如FileInputStream提供的字节流，但是业务上想操作字符流，于是提供InputStreamReader做为适配器，适配字节流到字符流。
示例：
java
代码解读
复制代码
// 使用 InputStreamReader 适配字节流到字符流 InputStreamReader isr = new InputStreamReader(new FileInputStream(__));
网页设计支付场景 第6篇
工厂模式顾名思义就是生产东西，使用者只管向工厂说我要什么，至于怎么生产，那是工厂的事。
严格意义上的工厂模式区分为工厂方法，抽象工厂。在工厂方法中，只定义创建对象的方法，再由具体的工厂类来实现，而抽象工厂就更为复杂一些。
但我们日常研发中使用更多的是非常简单的工厂，也就是所谓的简单工厂，比如在前面责任链模式中介绍的创建链的工厂类GatewayHandlerFactory，由工厂负责构建处理器责任链，使用者只调用getHandlers()来获得处理器列表，不关心生产的细节。
csharp
代码解读
复制代码
public class GatewayHandlerFactory { private static final List
网页设计支付场景 第7篇
在大学的时候，就开始翻GoF的设计模式，当时啃了好久，还是不甚了解，后来只好放弃。以至在毕业多年后仍然在写面条式代码，感觉没有什么是if else和for循环搞不定的事。
写多了，也看多了，慢慢开始对设计模式有了一些新的理解。
前段时间和一个朋友聊天，他说他请了一个教练在学羽毛球，我问他有什么心得，他说：“没请教练前，觉得自己也会打羽毛球，不就是挥挥拍子把球接住再打出去吗，请了教练后，才知道握拍、手腕发力等都是有一整套科学理论的，想打好一定要学会应用这些理论。”
软件的设计模式其实也是如此，掌握了编程语言的基本语法，会写if else和for，的确就可以写代码了，但是想写出高水平的代码，离不开设计模式这一理论的熟练应用。
网页设计支付场景 第8篇
对软件设计模式的理解和应用，基本上可以算做初级研发工程师和高级研发工程师的分水岭。
我在面试时很喜欢问候选人对设计模式的理解，以及实际应用情况，大部分候选人都能回答单例，工厂等，再多问几句，就惨不忍睹。其实也能理解，这些内容对于初学者而言，基本只能靠死记硬背，记不长久。
今天聊聊我理解的设计模式，在支付系统经常用到的场景，以及容易混淆的点，里面讲到的概念可能和一些权威的论述有所出入。
下面的内容全部源自我这么多年所写代码的抽象总结，和以前一样，也不可避免会夹杂一些我个人不成熟的见解，请各位以“取其精华，去其糟粕”的精神辩证地看待此文内容。
网页设计支付场景 第9篇
建造者和工厂都是创建型设计模式，都用于构建复杂的对象，但两者各有不同的侧重点。工厂模式对外提供一个接口构建对象，调用者不知道构建细节，而建造者模式需要调用者知道构建细节。
比如前面生成责任链的工厂，只对外提供一个getHandlers()，而在建造者模式示例中，调用者需要针对每个参数做设置。
代理、装饰器、中介者也经常容易混淆。三个都可以在不修改原有代码的基础上增加能力，区别在于：
代理和装饰器都是封装一个被访问对象，而中介者封装多个对象。
代理不修改被访问对象的业务能力，装饰器增加了业务处理能力。
在前面的例子中，BufferedInputStream封装InputStream是装饰器，InputStreamReader封装FileInputStream却是适配器。因为前者都是字节流，BufferedInputStream只是扩展了缓冲读写的能力，而后者是提供字节流到字符流的转换。
装饰器示例：两个类处理的都是字节流。
ini
代码解读
复制代码
// 使用装饰器增加缓冲功能 BufferedInputStream bis = new BufferedInputStream(FileInputStream(__));
适配器示例：字节流到字符串转换。
java
代码解读
复制代码
// 使用 InputStreamReader 适配字节流到字符流 InputStreamReader isr = new InputStreamReader(new FileInputStream(__));
观察者模式通常用于单机环境，适用简单的一对多场景。
发布-订阅需要用到消息中间件，适用于复杂的解耦通信场景。
网页设计支付场景 第10篇
观察者模式从名字上已经非常清楚，也就是当一个对象的状态发生改变时，所有依赖于它的对象都会得到通知。
这里面的重点仍然是职责单一原则，被观察者只需要处理自己的业务，然后把自己的变更通知到各观察者，再由各观察者根据这些变更，去处理自己的业务。
支付系统应用的场景非常多，比如为提高运算速度，支付方式被缓存在内存中，运营人员如果在后台关闭了某个支付方式，那就需要通知所有的机器刷新缓存，就可以用到观察者模式。
手机客户端程序里面按钮事件处理，也是典型的观察者模式。
示例：
arduino
代码解读
复制代码
// 观察者接口 public interface PaymentStateListen { void stateChanged(Order order); } // 被观察者接口 public interface OrderService { void registerPaymentStateListen(PaymentStateListen listen); void unregisterPaymentStateListen(PaymentStateListen listen); void notifyPaymentStateListens(Order order); } // 具体被观察者 public class OrderServiceImpl implements OrderService { private List
网页设计支付场景 第11篇
有些设计模式过于简单，有些在支付系统中比较少用，就不一一做详细介绍。
比较简单的设计模式且大家经常在使用的有：
单例模式（Singleton）：写代码的小伙伴多少都写过单例，还经常有所谓懒加载的讨论。
原型模式（Prototype）：java里面clone就是一个典型的实现，也经常有浅拷贝出现问题后，转而自己实现深拷贝的情况。
在支付系统中比较少用的设计模式有：
享元模式（Flyweight）（留意与缓存的区别。在渠道开关可以考虑使用）、桥接模式（Bridge）、命令模式（Command）、备忘录模式（Memento）（加入审批流的配置变更需要用到备忘录模式）、访问者模式（Visitor）、解释器模式（Interpreter）（如果实现自己的规则引擎会用到）等；
网页设计支付场景 第12篇
模板方法简单地理解就是预先定义了一个执行的框架，把公共的部分抽出来，一些具体的业务处理让子类去完成。
支付系统也有很多地方会用到，比如在服务的入口使用模板方法，负责异常处理，返回值封装等，业务代码只需要管业务逻辑就行。
同时在支付系统中，一般比较少用声明式事务，而是使用事务模板，但是spring 原生的事务模板有一定的缺陷，需要我们自己扩展。
下面是一个扩展spring事务模板的例子：
ini
代码解读
复制代码
public class FlowTransactionTemplate { public static
使用：
scss
代码解读
复制代码
public void process(FlowContext context) { (()); List
可以看到在模板里面，定义了主处理，异常处理，事务提交和回滚，事务提交后处理等逻辑，真正的业务代码只需要管业务代码怎么写就行。
网页设计支付场景 第13篇
中介者模式通过一个中介对象来封装一系列对象的访问。
一个典型的案例就是支付引擎。支付引擎做为一个中介者，封装了多个支付工具，比如余额、营销（比如红包，随机减等）、外部支付渠道等。
上游的收单、资金产品等都需要用到支付工具，就只需要调用支付引擎就行。如果没有支付引擎这个中介者，上游的多个应用都需要对接下游的多个支付工具。
网页设计支付场景 第14篇
策略模式最简单的理解就是用于替换if else。简单的代码，通常使用if else就已经足够，不需要杀鸡用牛刀，但是当每个if里面的代码逻辑都非常复杂，且预见后面可能还会增加，那就推荐使用策略模式。
这也是职责单一原则和扩展开放修改关闭的体现，一个策略只搞定一个if分支的逻辑就够，需要新增业务时，只需要新增策略，不需要修改原有代码。
支付系统使用策略模式也比较多，比如在跨境场景下接了很多外部渠道，各国的渠道接口对于请求号的要求是不一样的，有些要求使用32字符串，有些要求16位，有些要求固守字符开头等。这个时候就可以使用策略模式，预先制定好策略，不同的渠道配置不同的策略，根据不同的策略生成不同格式的请求号。
下面是一个简单的示例：
typescript
代码解读
复制代码
// 策略接口 public interface BuildRequestNoStrategy { // 根据通用的requestNo生成特定格式的requestNo String build(String requestNo, String ext); // 策略名 String name(); } // 16位长度的策略 public class Len16Strategy implements BuildRequestNoStrategy { @Override public String build(String requestNo, String ext) { // 拼接代码略 return buildLen16(requestNo); } } // 32位且固定前缀策略 public class PrefixLen32 implements BuildRequestNoStrategy { @Override public String build(String requestNo, String ext) { // 拼接代码略 return prefixLen32(requestNo, ext); } } // 其它策略代码略 ... ... // 策略工厂 public class BuildRequestNoStrategyFactory { // 初始化代码略 ... ... // 获取策略 public BuildRequestNoStrategy getStrategy(String name) { return (name); } } // 使用 public class PayServiceImpl implements PayService { public Order pay(Order order) { // 其它代码略 ... ... // 设置渠道请求号 (buildChannelRequestNo(())); // 其它代码略 ... ... } // 根据渠道配置的策略生成不同的格式的单号 private String buildChannelRequestNo(Channel channel) { // 生成默认请求号 String requestNo = buildDefaultRequestNo(); // 获取策略 RequestNoStrategyInfo strategyInfo = (); if (null == strategyInfo) { return requestNo; } BuildRequestNoStrategy strategy = ( ()); if (null == strategy) { return requestNo; } return (requestNo, ()); } }
网页设计支付场景 第15篇
责任链模式很简单，简单地理解就是把处理器一个个串起来，每个处理器只关心自己的那一部分实现就可以。
这个很像工厂里面的流水线作业，每个节点（或工人）只做一件事，从终点出来的就是一个成品。
在支付系统中应用也非常广泛，举两个典型场景：
如果不用责任链，那就写很多for循环和if else，随着支付方式多起来，业务逻辑越来越复杂，后面维护成本必须很高。如果使用责任链，每种判断都实现不同的处理器，把处理器串起来，依次执行完成，结果就出来了。
一个简单的示例：
GatewayHandler 接口定义了处理逻辑的执行方法。
csharp
代码解读
复制代码
public interface GatewayHandler { void process(GatewayContext context); }
具体的 Handler 实现：
内部参数转外部参数Handler
typescript
代码解读
复制代码
public class ParameterTransformHandler implements GatewayHandler { @Override public void process(GatewayContext context) { // 实现内部参数到外部参数的转换逻辑 } }
签名Handler
typescript
代码解读
复制代码
public class SignatureHandler implements GatewayHandler { @Override public void process(GatewayContext context) { // 不需要签名 if (!()) { return; } (sign((), ().getSignConfig())); } // 签名方法略 }
其它Handler的实现略。
GatewayHandlerFactory 是一个工厂类，用于构建处理责任链。
csharp
代码解读
复制代码
public class GatewayHandlerFactory { private static final List
执行Service
java
代码解读
复制代码
public class GatewayServiceImpl implements GatewayService { @Override public GatewayResponse process(GatewayRequest request) { // 转成网关的上下文 GatewayContext context = buildGatewayContext(request); // 获取责任链，依次执行 List
网页设计支付场景 第16篇
对于初学者，设计模式里面的很多东西，我们日常其实都在使用，只是没有意识到，也就是所谓的“日用而不自知”，只是有大佬们把这些给总结出来后，我们可以依此做一些刻意练习，以达到在需要的时候能够“信手拈来”。
软件行业有一些流行很广的理论或原则，比如：低耦合高内聚，扩展开放修改关闭，依赖倒置，单一职责，最少知识原则等，简单地理解，就是隔离策略， 内部复杂实现，外部简单调用，更通俗地说：“把复杂留给自己，把简单留给别人”。
回到设计模式，基本上也都符合这些基本原则：比如代理模式、装饰器模式等都扩展了新的能力却不必修改原有代码（扩展开放修改关闭）；外观模式、工厂模式等调用方只需要自己要用什么，不需要知道对方怎么实现（最少知识原则）；责任链模式和策略模式里面每一个处理器或策略只需要处理一个小功能（单一职责），其它的不一一列举。
网页设计支付场景 第17篇
建造者模式就是通过提供一个建造者类，逐步构建复杂对象的各个部分，并在最后调用build()方法时返回最终构建的对象。
更简单的理解，就是把PO类的setXXX方法给封装起来，使代码更简洁，尤其是当类的属性很多的时候。
常用的实现方式是直接在PO类的上面使用@注解。
示例：
less
代码解读
复制代码
@Data @Builder @ToString public class GatewayResponse { private boolean success; private String errorMessage; private String responseContext; }
使用：
typescript
代码解读
复制代码
public class GatewayServiceImpl implements GatewayService { private GatewayResponse buildResponse(String assembledResponseMessage) { return () .success(true) .responseContext(assembledResponseMessage) .build(); } // 其它方法略 }