java设计模式之模板方法设计模式

什么是模板方法设计模式

        模板方法是基于继承实现的,在抽象父类中声明一个模板方法,并在模板方法中定义算法的执行步骤(即算法骨架)。在模板方法模式中,可以将子类共性的部分放在父类里实现,而特性部分在子类中实现,只需将特性部分在父类中声明成抽象方法即可,使得子类可以在不改变算法结构的情况下重新定义算法中的步骤,不同的子类可以以不同的方式来实现这些逻辑。

        模板方法模式是所有模式中最为常见的几个模式之一,是基于继承的代码复用的基本技术,没有关联关系。 因此,在模板方法模式的类结构图中,只有继承关系。

核心设计点

AbstractClass : 抽象类,定义并实现一个模板方法。这个模板方法定义了算法的骨架,而逻辑的组成步骤在相应的抽象操作中,推迟到子类去实现

ConcreteClass : 实现父类所定义的一个或多个抽象方法。

模板方法模式优缺点

优点:模板方法模式通过把不变的行为搬移到父类,去除了子类中的重复代码。子类实现算法的某些细节,有助于算法的扩展。通过一个父类调用子类实现的操作,通过子类扩展增加新的行为,符合“开放-封闭原则”。

缺点:每个不同的实现都需要定义一个子类,这会导致类的个数的增加,设计更加抽象。

案例一(支付回调)

比如我们开发了一个商城系统,商城支付的时候我们收银台集成了支付宝支付、微信支付、银联支付,调用第三方支付平台之后支付完了那支付平台是不是要给我们收银台返回一个支付结果(支付回调)

 所以这个时候我们应该暴漏一个接口供第三方支付平台回调使用,由于不同支付平台回调通知的参数报文不一样,但是通知行为是一样的,因此通知行为可以在抽象类中定义为模板方法的骨架,不同的参数报文解析由各支付回调子类来进行解析

当第三方支付平台回调过来的时候大致执行下面步骤:

1、报文验签 2、日志入库记录 3、报文解析返回回调状态

下面直接代码展示,首先就是定义抽象类,里面定义共同行为的方法骨架:asyncCallBack

其中验签操作和业务解析定义为抽象方法,由子类进行实现,因为不同支付平台验签方式不一样所以要放在子类中实现,业务解析也一样;我们看到返回成功或者失败也定义为了抽象方法由子类实现是因为不同支付平台要求的返回格式不一样,有的可能要求返回success,有的则要求是返回ok,因此也由子类实现。

 然后是支付宝支付子类实现模板抽象方法(报文为模拟效果报文)

  然后是银联支付子类实现模板抽象方法(报文为模拟效果报文)

 然后通过工程模式来生成对象

 

最后我们写一个controller测试一下

 启动服务访问测试

 

 看到效果了吗兄弟们,成功

案例二(买车-大众迈腾)

        再实现一个案例,就是买车案例,孙悟空和天津饭都需要买大众迈腾,假如买车分为三步骤:起床穿衣服、银行取钱、4s店提车。

        共同点:都需要买大众迈腾

        异同点:起床穿衣服不同的人穿的衣服不一样,不同的人取钱的银行不一样

所以我们可以把买车这个共同行为定义为一个模板方法,起床穿衣服和银行取钱的操作由子类实现

下面代码实现,首先定义抽象类模板方法

 然后是孙悟空买车的子类实现

  然后是天津饭买车的子类实现

 然后我们使用controller测试一下

测试孙悟空买车:

 

 

 测试天津饭买车:

 

 案例到此结束,源代码已经上传码云:https://gitee.com/vancl/strategy/commit/a5a49bb480edcab981dce4f01bab31d5979922e9

  • 3
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 1
    评论

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

酒书

你的鼓励是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值