支付场景业务关联设计模式

用工厂模式设计支付业务场景,包含跨境支付,支付宝、微信、银联支付,并画出类图

1: 理清题目要求并扩展题目, 题目要求是用工程模式设计支付业务场景

假设第一个场景是: 已经存在统一支付接口,支付宝接口,微信支付接口,银联支付接口,于是画下设计图(不是类图),

写出代码如下:(第一个是简单工厂模式)

public interface IPayment {

    /**
     * 支付金额
     * @param money
     */
    void pay(Double money);
}

public class AliPayment implements IPayment {
    @Override
    public void pay(Double money) {
        System.out.println("使用支付宝支付金额: " + money);
    }
}
public class OverseasPayment implements IPayment {
    @Override
    public void pay(Double money) {
        System.out.println("使用境外支付金额: " + money);
    }
}
public class UnionPayment implements IPayment {
    @Override
    public void pay(Double money) {
        System.out.println("使用银联支付金额: " + money);
    }
}
public class WechatPayment implements IPayment {
    @Override
    public void pay(Double money) {
        System.out.println("使用微信支付金额: " + money);
    }
}

public class PaymentFactory {
    public static final String ALI = "ali";
    public static final String WECHAT = "wechat";
    public static final String UNION = "union";
    public static final String OVERSEA = "oversea";

    /**
     * 創建 支付方式
     * @param params
     * @return
     */
    public static IPayment createPayment(String params) {
        if(ALI.equalsIgnoreCase(params)) {
            return new AliPayment();
        } else if(WECHAT.equalsIgnoreCase(params)) {
            return new WechatPayment();
        } else if(UNION.equalsIgnoreCase(params)) {
            return new UnionPayment();
        } else if(OVERSEA.equalsIgnoreCase(params)) {
            return new OverseasPayment();
        } else {
            return null;
        }
    }
}
public class SimpleFactoryPayTest {

    public static void main(String[] args) {
        String params = "ali";
        IPayment payment = PaymentFactory.createPayment(params);
        Double money = 6.2;
        payment.pay(money);
    }
}

具体类图UML图:

从上面的代码中我们能发现出很多问题

1: 扩展问题, 境外统一支付是后面新接入的接口,如果原理的判断逻辑没有编写的话,那么就需要更改代码判断逻辑,这样做

提高了代码变更造成的风险,违背了开闭原则.

2: 所以的支付都比较抽象,都没有说明是如何支付的,支付的细节没有任何的提现,无法应用到实际中,甚至连参考都谈不上.

既然知道了问题,那么我们就开始对上面的问题做一点改造,改造的引领思路如下:

1: 为了提高扩展性,我们都要习惯性的面向抽象编程.

2: 为了提高扩展性, 我们都要习惯在熟知业务的情况下看看是否可以用设计模式(综合使用设计模式)进行改造.

于是我们对业务场景做出改变,

支付分为国内支付和国外支付,然后国外支付有不同的支付渠道及方式,比如苹果支付,同时国外也有相同的支付方式,支付宝支付,

微信支付,银联支付,这个层面还是对支付方式上面的一个设计,设计如下: (抽象工厂模式)

支付场景设计如下: 在页面上面我们可以选择不同的支付方式,

首先是国内,国外单选框选择,

选择国内: 有如下图显示方式

选择国外: 有如下图显示方式

编写相关代码如下:

public interface IPayment2 {

    /**
     * 支付金额
     * @param money
     */
    void pay(Double money);
}

public interface IPaymentFactory {

    IPayment2 createAliPayment();
    IPayment2 createWechatPayment();
    IPayment2 createUnionPayment();
}

public class AbstractFactoryTest {

    public static void main(String[] args) {
        HomePaymentFacotry homePaymentFacotry = new HomePaymentFacotry();
        Double money = 7.8;
        homePaymentFacotry.createAliPayment().pay(money);

        ForeignPaymentFacotry foreignAliPayment = new ForeignPaymentFacotry();
        foreignAliPayment.createAliPayment().pay(money);
        foreignAliPayment.createApplePayment().pay(money);
    }
}


public class ForeignAliPayment implements IPayment2 {

    @Override
    public void pay(Double money) {
        System.out.println("国外支付宝支付金额: " + money);
    }
}

public class ForeignApplePayment implements IPayment2 {

    @Override
    public void pay(Double money) {
        System.out.println("国外苹果宝支付金额: " + money);
    }
}


public class ForeignPaymentFacotry implements IPaymentFactory{

    @Override
    public IPayment2 createAliPayment() {
        return new ForeignAliPayment();
    }

    @Override
    public IPayment2 createWechatPayment() {
        return new ForeignWechatPayment();
    }

    @Override
    public IPayment2 createUnionPayment() {
        return new ForeignUnionPayment();
    }

    //扩展出 苹果支付
    public IPayment2 createApplePayment() {
        return new ForeignApplePayment();
    }
}


public class ForeignUnionPayment implements IPayment2 {

    @Override
    public void pay(Double money) {
        System.out.println("国外银联支付金额: " + money);
    }
}

public class ForeignWechatPayment implements IPayment2 {
    
    @Override
    public void pay(Double money) {
        System.out.println("国外微信支付金额: " + money);
    }
}

public class HomeAliPayment implements IPayment2 {
    @Override
    public void pay(Double money) {
        System.out.println("国内支付宝支付金额: " + money);
    }
}


public class HomePaymentFacotry implements IPaymentFactory {
    @Override
    public IPayment2 createAliPayment() {
        return new HomeAliPayment();
    }

    @Override
    public IPayment2 createWechatPayment() {
        return new HomeWechatPayment();
    }

    @Override
    public IPayment2 createUnionPayment() {
        return new HomeUnionPayment();
    }
}

public class HomeUnionPayment implements IPayment2 {
    @Override
    public void pay(Double money) {
        System.out.println("国内银联支付金额: " + money);
    }
}

public class HomeWechatPayment implements IPayment2 {
    @Override
    public void pay(Double money) {
        System.out.println("国内微信支付金额: " + money);
    }
}


导出UML类图如下:

如果要在跨境支付(国外支付)下面添加一个PayPal, 直接新增一个类: PayPalPayment,

public class ForeignPayPalPayment implements IPayment2 {
    @Override
    public void pay(Double money) {
        System.out.println("国外使用PayPal支付金额: " + money);
    }
}

修改代码: 

public class ForeignPaymentFacotry implements IPaymentFactory{

    @Override
    public IPayment2 createAliPayment() {
        return new ForeignAliPayment();
    }

    @Override
    public IPayment2 createWechatPayment() {
        return new ForeignWechatPayment();
    }

    @Override
    public IPayment2 createUnionPayment() {
        return new ForeignUnionPayment();
    }

    //扩展出 苹果支付
    public IPayment2 createApplePayment() {
        return new ForeignApplePayment();
    }

    //新增PayPal支付
    public IPayment2 createPayPalPayment() {
        return new ForeignPayPalPayment();
    }
}

符合开闭原则, 对扩展开放,对修改关闭,只需要新增一个类,新增一个方法即可完成PayPal支付方式的增加.

 

触类旁通:

支付场景除了涉及到工厂模式还有一系列其他的设计模式,

比如策略模式(对具体的支付算法的封装设计)

比如状态模式(对支付状态的一个设计)

还有一些非常重要的常用的支付业务,

例如聚合支付

涉及到单例模式

涉及到适配器模式

至于以上涉及到的设计模式分析详见下章节.

参考链接:

https://www.cnblogs.com/lyc94620/p/13055116.html

https://blog.csdn.net/wwsl123/article/details/107405452

https://www.cnblogs.com/lkqm/p/6476731.html

https://my.oschina.net/10000000000/blog/4358606

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
UML和模式应用(原书第3版) 原书名: Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition) 原出版社: Prentice Hall PTR 作者: (美)Craig Larman [作译者介绍] 译者: 李洋[同译者作品] 郑龑 出版社:机械工业出版社 目录 第一部分 绪 论 第1章 面向对象分析和设计 1.1 本书的主要内容 1.2 最重要的学习目标 1.3 什么是分析和设计 1.4 什么是面向对象分析和设计 1.5 简短示例 1.6 什么是UML 1.7 可视建模的优点 1.8 历史 1.9 参考资料 第2章 迭代、进化和敏捷 2.1 什么是UP?其他方法能否对其进行补充 2.2 什么是迭代和进化式开发 2.3 什么是瀑布生命周期 2.4 如何进行迭代和进化式分析和设计 2.5 什么是风险驱动和客户驱动的迭代计划 2.6 什么是敏捷方法及其观点 2.7 什么是敏捷建模 2.8 什么是敏捷UP .2.9 UP的其他关键实践 2.10 什么是UP的阶段 2.11 什么是UP科目 2.12 如何定制过程和UP开发案例 2.13 判断你是否理解迭代开发或UP 2.14 历史 2.15 参考资料 第3章 案例研究 3.1 案例研究中涵盖的内容 3.2 案例研究策略:迭代开发+迭代学习 3.3 案例一:NextGen POS系统 3.4 案例二:Monopoly游戏系统 第二部分 初 始 阶 段 第4章 初始不是需求阶段 4.1 什么是初始 4.2 初始阶段的持续时间 4.3 初始阶段会创建的制品 4.4 何时知道自己并不了解初始阶段 4.5 初始阶段中有多少UML 第5章 进化式需求 5.1 定义:需求 5.2 进化式需求与瀑布式需求 5.3 寻找需求可以采用的方法 5.4 需求的类型和种类 5.5 UP制品如何组织需求 5.6 本书是否包含这些制品的示例 5.7 参考资料 第6章 用例 6.1 示例 6.2 定义:参与者、场景和用例 6.3 用例和用例模型 6.4 动机:为什么使用用例 6.5 定义:用例是功能性需求吗 6.6 定义:参与者的三种类型 6.7 表示法:用例的三种常用形式 6.8 示例:详述风格的处理销售 6.9 各小节的含义 6.10 表示法:有其他格式吗?两栏变体 6.11 准则:以无用户界面约束的本质风格编写用例 6.12 准则:编写简洁的用例 6.13 准则:编写黑盒用例 6.14 准则:持有参与者和参与者目标的视点 6.15 准则:如何发现用例 6.16 准则:什么样的测试有助于发现有用的用例 6.17 应用UML:用例图 6.18 应用UML:活动图 6.19 动机:用例还有其他益处吗?语境中的需求 6.20 示例:Monopoly游戏 6.21 过程:在迭代方法中如何使用用例 6.22 历史 6.23 参考资料 第7章 其他需求 7.1 如何完成这些示例 7.2 准则:初始阶段是否应该对此彻底地进行分析 7.3 准则:这些制品是否应该放在项目Web站点上 7.4 NextGen示例:(部分)补充性规格说明 7.5 注解:补充性规格说明 7.6 NextGen示例:(部分)设想 7.7 注解:设想 7.8 NextGen示例:(部分)词汇表 7.9 注解:词汇表(数据字典) 7.10 NextGen示例:业务规则(领域规则) 7.11 注解:领域规则 7.12 过程:迭代方法中的进化式需求 7.13 参考资料 第三部分 细化迭代1—基础 第8章 迭代1—基础 8.1 迭代1的需求和重点:OOA/D技术的核心 8.2 过程:初始和细化 8.3 过程:计划下一个迭代 第9章 领域模型 9.1 示例 9.2 什么是领域模型 9.3 动机:为什么要创建领域模型 9.4 准则:如何创建领域模型 9.5 准则:如何找到概念类 9.6 示例:寻找和描绘概念类 9.7 准则:敏捷建模—类图的草呼 9.8 准则:敏捷建模—是否要使用工具维护模型 9.9 准则:报表对象—模型中是否要包括“票据” 9.10 准则:像地图绘制者一样思考;使用领域术语 9.11 准则:如何对非现实世界建模 9.12 准则:属性与类的常见错误 9.13 准则:何时使用“描述”类建模 9.14 关联 9.15 示例:领域模型中的关联 9.16 属性 9.17 示例:领域模型中的属性 9.18 结论:领域模型是否正确 9.19 过程:迭代和进化式领域建模 9.20 参考资料 第10章 系统顺序图 10.1 示例:NextGen SSD 10.2 什么是系统顺序图 10.3 动机:为什么绘制SSD 10.4 应用UML:顺序图 10.5 SSD和用例之间的关系 10.6 如何为系统事件和操作命名 10.7 如何为涉及其他外部系统的SSD建模 10.8 SSD的哪些信息要放入词汇表中 10.9 示例:Monopoly SSD 10.10 过程:迭代和进化式SSD 10.11 历史和参考资料 第11章 操作契约 11.1 示例 11.2 定义:契约有哪些部分 11.3 定义:什么是系统操作 11.4 定义:后置条件 11.5 示例:enterItem后置条件 11.6 准则:是否应该更新领域模型 11.7 准则:契约在何时有效 11.8 准则:如何创建和编写契约 11.9 示例:NextGen POS契约 11.10 示例:Monopoly契约 11.11 应用UML:操作、契约和OCL 11.12 过程:UP的操作契约 11.13 历史 11.14 参考资料 第12章 迭代地从需求到设计 12.1 以迭代方式做正确的事,正确地做事 12.2 尽早引发变更 12.3 完成所有分析和建模工作是否需要几个星期 第13章 逻辑架构和UML包图 13.1 示例 13.2 什么是逻辑架构和层 13.3 案例研究中应该关注的层 13.4 什么是软件架构 13.5 应用UML:包图 13.6 准则:使用层进行设计 13.7 准则:模型-视图分离原则 13.8 SSD、系统操作和层之间的联系 13.9 示例:NextGen的逻辑架构和包图 13.10 示例:Monopoly逻辑架构 13.11 参考资源 第14章 迈向对象设计 14.1 敏捷建模和轻量级UML图形 14.2 UML CASE工具 14.3 编码前绘制UML需要花费多少时间 14.4 设计对象:什么是静态和动态建模 14.5 基于UML表示法技术的对象设计技术的重要性 14.6 其他对象设计技术:CRC卡 第15章 UML交互图 15.1 顺序图和通信图 15.2 UML建模初学者没有重视交互图 15.3 常用的UML交互图表示法 15.4 顺序图的基本表示法 15.5 通信图的基本表示法 第16章 UML类图 16.1 应用UML:常用类图表示法 16.2 定义:设计类图 16.3 定义:类元 16.4 表示UML属性的方式:属性文本和关联线 16.5 注解符号:注解、注释、约束和方法体 16.6 操作和方法 16.7 关键字 16.8 构造型、简档和标记 16.9 UML特性和特性字符串 16.10 泛化、抽象类、抽象操作 16.11 依赖 16.12 接口 16.13 组合优于聚合 16.14 约束 16.15 限定关联 16.16 关联类 16.17 单实例类 16.18 模板类和接口 16.19 用户自定义的分栏 16.20 主动类 16.21 交互图和类图之间的关系 第17章 GRASP:基于职责设计对象 17.1 UML与设计原则 17.2 对象设计:输入、活动和输出的示例 17.3 职责和职责驱动设计 17.4 GRASP:基本OO设计的系统方法 17.5 职责、GRASP和UML图之间的联系 17.6 什么是模式 17.7 现在我们所处的位置 17.8 使用GRASP进行对象设计的简短示例 17.9 在对象设计中应用GRASP 17.10 创建者 17.11 信息专家(或专家) 17.12 低耦合 17.13 控制器 17.14 高内聚 17.15 参考资料 第18章 使用GRASP的对象设计示例 18.1 什么是用例实现 18.2 制品注释 18.3 下一步工作 18.4 NextGen迭代的用例实现 18.5 Monopoly迭代的用例实现 18.6 过程:迭代和进化式对象设计 18.7 总结 第19章 对可见性进行设计 19.1 对象之间的可见性 19.2 什么是可见性 第20章 将设计映射为代码 20.1 编程和迭代、进化式开发 20.2 将设计映射到代码的 20.3 由DCD创建类的定义 20.4 从交互图创建方法 20.5 代码中的集合类 20.6 异常和错误处理 20.7 定义Sale.makeLineItem方法 20.8 实现的顺序 20.9 测试驱动或测试优先的开发 20.10 将设计映射为代码的总结 20.11 NextGen POS程序简介 20.12 Monopoly程序简介 第21章 测试驱动开发和重构 21.1 测试驱动开发 21.2 重构 21.3 参考资料 第四部分 细化迭代2—更多模式 第22章 UML工具与视UML为蓝图 22.1 前向、逆向和双向工程 22.2 什么是有价值特性的常见报告 22.3 对工具有哪些期待 22.4 如果绘制了UML草图,如何在编码后更新该图形 22.5 参考资料 第23章 快速地更新分析 23.1 案例研究:NextGen POS 23.2 案例研究:Monopoly 第24章 迭代2:更多模式 24.1 从迭代1到迭代2 24.2 迭代2的需求和重点:对象设计和模式 第25章 GRASP:其他对象职责 25.1 多态 25.2 纯虚构 25.3 间接性 25.4 防止变异 第26章 应用GoF设计模式 26.1 适配器(GoF) 26.2 一些GRASP原则是对其他设计模式的归纳 26.3 设计中发现的“分析”:领域模型 26.4 工厂(Factory) 26.5 单实例类(GoF) 26.6 具有不同接口的外部服务问题的结论 26.7 策略(GoF) 26.8 组合(GoF)和其他设计原则 26.9 外观(Facade,GoF) 26.10 观察者/发布-订阅/委派事件模型(GoF) 26.11 结论 26.12 参考资料 第五部分 细化迭代3—中级主题 第27章 迭代3:中级主题 27.1 NextGen POS案例 27.2 Monopoly案例 第28章 UML活动图及其建模 28.1 示例 28.2 如何应用活动图 28.3 其他UML活动图表示法 28.4 准则 28.5 示例:NextGen中的活动图 28.6 过程:“统一过程”中的活动图 28.7 背景 第29章 UML状态机图和建模 29.1 示例 29.2 定义:事件、状态和转换 29.3 如何应用状态图 29.4 更多UML状态机图表示法 29.5 示例:使用状态机进行UI导航建模 29.6 示例:NextGen用例的状态机图 29.7 过程:UP中的状态机图 29.8 推荐资源 第30章 用例关联 30.1 包含关系 30.2 术语:具体用例、抽象用例、基础用例和附加用例 30.3 扩展关系 30.4 泛化关系 30.5 用例图 第31章 更多的SSD和契约 第32章 精化领域模型的精化 32.1 NextGen领域模型中的新概念 32.2 泛化 32.3 定义概念超类和子类 32.4 何时定义概念子类 32.5 何时定义概念超类 32.6 NextGen POS案例中的概念类层次结构 32.7 抽象概念类 32.8 对变化的状态建模 32.9 软件中的类层次结构和继承关系 32.10 关联类 32.11 聚合关系和组合关系 32.12 时间间隔和产品价格—解决迭代1阶段的“错误” 32.13 关联角色名称 32.14 作为概念的角色与关联中的角色 32.15 导出元素 32.16 受限关联 32.17 自反关联 32.18 使用包来组织领域模型 32.19 示例:Monopoly领域模型的精化 第33章 架构分析 33.1 过程:何时开始架构分析 33.2 定义:变化点和进化点 33.3 架构分析 33.4 架构分析的常用步骤 33.5 科学:架构因素的识别和分析 33.6 示例:NextGen POS的部分架构因素表 33.7 艺术:架构性因素的解决 33.8 架构分析主题的总结 33.9 过程:UP中的迭代架构 33.10 参考资料 第34章 逻辑架构精化 34.1 示例:NextGen的逻辑架构 34.2 使用层模式的协作 34.3 有关层模式的其他问题 34.4 模型-视图分离和“向上”通信 34.5 参考资料 第35章 使用GoF模式完成更多对象设计 35.1 示例:NextGen POS 35.2 本地服务容错;使用本地缓存提高性能 35.3 处理故障 35.4 通过代理(PGoF)使用本地服务进行容错 35.5 对非功能性或质量需求的设计 35.6 使用适配器访问外部物理设备 35.7 对一组相关的对象使用抽象工厂模式 35.8 使用多态性和“Do It Myself”模式处理支付 35.9 示例:Monopoly案例 35.10 结论 第36章 包的设计 36.1 组织包结构的准则 36.2 参考资料 第37章 UML部署图和构件图 37.1 部署图 37.2 构件图 第38章 使用模式设计持久性框架 38.1 问题:持久性对象 32.2 解决方案:持久性框架提供的持久性服务 38.3 框架 38.4 持久性服务和框架的需求 38.5 关键思想 38.6 模式:将对象表示为表 38.7 UML数据建模简档 38.8 模式:对象标识符 38.9 通过外观访问持久服务 38.10 映射对象:数据库映射器或数据库代理模式 38.11 使用模板方法模式进行框架设计 38.12 使用模板方法模式的具体化 38.13 使用MapperFactory配置Mapper 38.14 模式:缓存管理 38.15 在类中合并和隐藏SQL语句 38.16 事务状态和状态模式 38.17 使用命令模式设计事务 38.18 使用虚代理实现滞后具体化 38.19 如何在表中表示关系 38.20 PersistentObject和关注分离 38.21 未决问题 第39章 架构的文档化:UML和N+1视图模型 39.1 SAD和架构视图 39.2 表示法:SAD的结构 39.3 示例:NextGen POS的SAD 39.4 示例:Jakarta Struts 的SAD 39.5 过程:迭代式架构文档 39.6 参考资料 第六部分 其 他 主 题 第40章 迭代式开发和敏捷项目管理的进一步讨论 40.1 如何计划一次迭代 40.2 适应性计划与预测性计划 40.3 阶段计划和迭代计划 40.4 如何使用用例和场景来计划迭代 40.5 早期预算的有效性(无效性) 40.6 将项目制品组织起来 40.7 何时你会发现自己并没有理解迭代计划 40.8 参考资料 参考文献

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值