支部网站建设,网站怎么创建自己的网站,建设网站的步骤,商业网站最佳域名为什么使用设计模式
今天终于有时间系统的整理一下这几个设计模式了#xff0c; 这几个真是最常用的#xff0c;用好了它们#xff0c;你就在也不用一大堆的if else 了。能更好的处理大量的代码冗余问题。
在我们的实际开发中#xff0c;肯定会有这样的场景#xff1a;我…为什么使用设计模式
今天终于有时间系统的整理一下这几个设计模式了 这几个真是最常用的用好了它们你就在也不用一大堆的if else 了。能更好的处理大量的代码冗余问题。
在我们的实际开发中肯定会有这样的场景我们的某个方法被多次重复调用但是每次呢还需要稍微的改动里面一部分的内容。但是我们常常的写法就是既然能复用那我就把原来的接口copy出来一份再改一该里面的内容。哦nice真快三下五除二解决但是这样的代码其实就真的只是能运行给后期运维会带来很大的压力。
倘若我们系统第一版本就这么开发完成了到第二版需求迭代时。 老板说“把某某某功能改一下原来的逻辑统一变了这个就小改动应该很快吧给你半天时间。” 然后你说“我靠那这工作量太大了 我每个接口都有这个代码这一变动就要全部修改我点需要两天时间。” 老板说“这么个破修改你要两天别再这摸鱼了啊半天肯定能完事我自己都能改完 半天改不完baibai” 然后你默默翻到我的文章周末两天连续加班修改了所有代码全用上了这套设计模式以后老板给你估算半天修改时间 你抢答说“不用一两个小时吧就够了”。哈哈哈
设计模式介绍 工厂模式Factory Pattern是一种创建型设计模式用于创建对象的实例化逻辑与客户端代码的分离。在工厂模式中通过工厂类封装实例化对象的过程客户端代码不需要直接调用构造函数来实例化对象而是通过工厂类来创建对象。这样可以提供更灵活性和可维护性且符合开闭原则。工厂模式常见的几种形式包括简单工厂模式、工厂方法模式和抽象工厂模式。 模板模式Template Pattern是一种行为设计模式用于定义算法的骨架将可变部分延迟到子类中实现。在模板模式中定义一个模板方法用于规定算法的流程同时定义一些抽象方法或钩子方法子类可以重写这些方法以定义具体实现。通过模板模式可以避免重复的代码并提供一个统一的算法框架。 策略模式Strategy Pattern是一种行为设计模式用于定义一系列算法并将每个算法封装成一个独立的策略对象客户端可以根据需要在运行时选择算法。在策略模式中算法之间可以互相替换独立于客户端并相互独立运行。策略模式可以提高代码的灵活性和复用性同时符合开闭原则。 实战代码讲解
常规写法
我们就拿最简单最热门的业务电商项目的支付功能来讲解。 首先我们创建一个支付的接口。
public interface WxPayService {void pay(PayParams payParams);
}public interface AliPayService {void pay(PayParams payParams);
}随便定义一下这个接口参数
Data
public class PayParams {private String name;
}然后像我们正常的Javaweb项目一样创建正常的MVC三层结构。
public class WxPayServiceImpl implements PayService{// 实现接口中的方法Overridepublic void pay(PayParams payParams) {// TODO 第一步检验一些数据参数是否合格// TODO 第二步微信支付具体步骤// TODO 第三步支付成功进行一些回写、赋值、返回等等操作。}
}public class AliPayServiceImpl implements PayService{// 实现接口中的方法Overridepublic void pay(PayParams payParams) {// TODO 第一步检验一些数据参数是否合格// TODO 第二步支付宝支付具体步骤// TODO 第三步支付成功进行一些回写、赋值、返回等等操作。}
}最后再定义一个controller层调用
Autowired
private WxPayService wxPayService;Autowired
private AliPayService aliPayService;PostMapping(value /WxPay)
public ResponseResult pay(RequestBody PayParams params) {wxPayService.pay(params);return ResponseResult.success();
}PostMapping(value /AliPay)
public ResponseResult pay(RequestBody PayParams params) {aliPayService.pay(params);return ResponseResult.success();
}
这样是实现了我们的支付功能一个微信支付一个支付宝支付。但是我们会发现这样写出来的代码冗余非常多。
接下来我把这个业务代码修改为使用设计模式的格式。
设计模式后的代码
首先我们还是创建一个支付接口。
public interface PayService {void pay(PayParams payParams);
}然后我们来实现这个接口因为我们目前就有两种支付方式等项目后续升级肯定还会接入越来越多的支付方式所以我们这里目前就要有两个实现类来实现这个接口 以后可能更多。 观看上图我们有发现在实际的业务逻辑中其实每个支付的代码中的第一步和第三步都是一样的所以我们可以把它抽离成一个模板。模板模式这就被使用了。代码如下
public abstract class PayServiceAbstract implements PayService{// 实现接口中的方法Overridepublic void pay(PayParams payParams) {before(payParams);realPay(payParams);after(payParams);}// 把这个核心支付功能定义为抽象的方法,留给具体的策略实现类去实现。public abstract void realPay(PayParams payParams);// 支付之前、之后的操作在抽象类中就定义一个模板方法// 只要掉用了这个抽象方法就自己有该模板可使用。public void before(PayParams payParams){System.out.println(支付前操作);}public void after(PayParams payParams){System.out.println(支付后操作);}
}上面代码中我们是用一个抽象类实现了接口但是抽象还不是具体的实现它只是固定了一个模板接下来我们就要有每个支付方式自己的类去做具体的实现这个也就是策略模式。对一个接口分别使用不同的策略来做不同的事。
支付宝支付的具体策略服务
Service
public class AliPayServiceAbstractImpl extends PayServiceAbstract{Overridepublic void realPay(PayParams payParams) {System.out.println(支付宝支付处理中。。。。);}
}微信支付的具体策略服务
Service
public class WxPayServiceAbstractImpl extends PayServiceAbstract{Overridepublic void realPay(PayParams payParams) {System.out.println(微信支付处理中。。。。);}
}ok到目前策略模式 模板模式就使用成功了每当需求再叠加时我们只需要再加一个具体的策略服务就ok了。别的地方都不需要动。
接下来时控制层的调用。我们如果还是用原来的controller定义一个微信支付接口一个支付宝支付接口那也太麻烦了。而且如果以后再有个银行卡支付apple支付那每次还要新增接口真麻烦。所以我们不妨使用工厂模式来解决这个问题让工厂来帮我们确定到底要用哪种支付。这样就来到了我们的工厂模式。
定义一个工厂
Service
public class PayFactory {// payType 哪个具体策略服务public PayServiceAbstract getFactory(String payType){try {Class? aClass Class.forName(com.bihe.controller.payType);PayServiceAbstract payServiceAbstract (PayServiceAbstract) aClass.getDeclaredConstructor().newInstance();return payServiceAbstract;} catch (Exception e) {throw new RuntimeException(e);}}
}上面的代码中我们是用了Java反射根据我们传递进来的类名自动反射创建出具体的策略对象。
最后就是我们的控制层了。
PostMapping(value /pay)public ResponseResult pay(RequestBody PayParams params) {PayServiceAbstract payServiceAbstract payFactory.getFactory(params.getName());payServiceAbstract.pay(params);return ResponseResult.success();}
这就非常简单了 我们永远只用这一样接口前端也不需要判断我什么时候调用weixin支付什么时候调用ali支付… 前端可以一直调用这个一个接口就可以了只是把响应支付的关键参数传递过来就可以了。
前端调用 啦这样的代码是不是非常的规整我们后续如果再添加一个新的支付接口就只需要再加一个具体的策略实现类就可以了如果老板还要修改以前的统一的业务逻辑那我们也是只需要在模板中也就是抽象类那层修改就可以啦。 哇代码终于干净了整个人都舒服了。哈哈 查看原文章可进入我的个人博客 沉思随笔 。欢迎大家
