当前位置:龙泉人才网 - 公司招聘 -

电商设计师(电商系统设计模式实战)

  • 公司招聘
  • 2023-08-10 10:10
  • 龙泉小编

1 代理模式

案例:根据文件类型,将文件存储到不同服务

代理模式:给一个对象创建一个代理对象,通过代理对象可以使用该对象的功能。

CGLib和JDK是代理模式实现的技术方案。

1.1 文件服务应用

代理模式的应用场景除了代码级别,还可以将代理模式迁移到应用以及架构级别,如下图文件上传代理服务,针对一些图片小文件,我们可以直接把文件存储到FastDFS服务,针对大文件,例如商品视频介绍,我们可以把它存储到第三方OSS。

用户通过文件上传代理服务可以间接访问OSS和本地FastDFS,这种分布式海量文件管理解决方案,这里不仅在代码层面充分运用了代理模式,在架构层面也充分运用了代理模式。

1.2 分布式文件代理服务器实现

1.2.1 实现分析

基于代理模式,我们实现文件上传分别路由到 aliyunOSS 和 FastDFS ,用例图如下:

讲解:

1、FileUpload抽象接口,定义了文件上传方法,分别给它写了2种实现。

2、AliyunOSSFileUpload是将文件上传到aliyunOSS,主要上传mp4和avi的视频大文件。

3、FastdfsFileUpoad是将文件上传到FastDFS,主要上传png/jpg等图片小文件。

4、FileUploadProxy是代理对象,供用户访问,调用了FileUpload的文件上传方法,为用户提供不同文件上传调用。

5、FileController是控制器,用于接收用户提交的文件,并调用代理FileUploadProxy实现文件上传。

1.2.2 代码实现

bootstrap.yml配置:

FileUpload接口定义:

AliyunOSSFileUpload实现:

FastdfsFileUpoad实现:

FileUploadProxy代理实现:

FileController控制器实现

2 享元模式

定义:运用共享技术来有效地支持大量细粒度对象的复用。它通过共享已经存在的对象来大幅度减少需要创建的对象数量、避免大量相似类的开销,从而提高系统资源的利用率。

享元模式和单利的区别:

单例是对象只能自己创建自己,整个应用中只有1个对象

享元模式根据需要共享,不限制被谁创建(有可能有多个对象实例)

优点:

特定环境下,相同对象只要保存一份,这降低了系统中对象的数量,从而降低了系统中细粒度对象给内存带来的压力。

缺点:

为了使对象可以共享,需要将一些不能共享的状态外部化,这将增加程序的复杂性

2.1 享元模式实战

案例:用户下单,会话共享

2.1.1 会话跟踪分析

会话跟踪,如果是传统项目用Session或者是Cookie,全项目通用,但在微服务项目中,不用Session也不用Cookie,所以想要在微服务项目中实现会话跟踪,是有一定难度的。

当前微服务项目中,身份识别的主流方法是前端将用户令牌存储到请求头中,每次请求将请求头中的令牌携带到后台,后台每次从请求头中获取令牌来识别用户身份。

我们在项目操作过程中,很多地方都会用到用户身份信息,比如下订单的时候,要知道当前订单属于哪个用户,记录下单关键日志的时候,需要记录用户操作的信息以及用户信息,关键日志记录我们一般用AOP进行拦截操作,此时没法直接把用户身份信息传给AOP。这个时候我们可以利用享元模式实现用户会话信息共享操作。操作流程如下图:

2.1.2 会话共享案例实现

基于上面的分析,我们采用享元模式实现用户会话共享操作,要解决如下几个问题:

定义共享组件: LogComponent

LogComponent 里面定义了每个线程中不变的用户身份信息 username 、 role 、 sex ,其他的是可能存在变化的数据,例如用于做日志记录的 methodName 、 message 。

享元组件逻辑操作对象: SupplementSource

SupplementSource 该对象主要用于给当前线程填充共享数据,以及变更访问方法和访问信息等信息的逻辑操作,代码如下:

多线程安全控制: ThreadUserLog

每个线程请求的时候,我们需要保障会话安全,比如A线程访问和B线程访问,他们的用户会话身份不能因为并发原因而发生混乱。这里我们可以采用ThreadLocal来实现。我们创建一个 ThreadUserLog 对象,并在该对象中创建ThreadLocal<LogComponent> 用户存储每个线程的会话信息,并实现 ThreadLocal<LogComponent> 的操作,代码如下:

线程会话初始化: AuthorizationInterceptor

AuthorizationInterceptor 拦截器的作用是用于初始化用户访问的时候用户的身份信息,并将身份信息存储到ThreadUserLog 的 ThreadLocal 中,在用户访问方法结束,销毁 ThreadUserLog 的 ThreadLocal 中会话,代码如下:

创建 MvcConfig 来配置拦截器 AuthorizationInterceptor ,代码如下:

共享信息使用:

①AOP记录日志:创建AOP切面类 LogAspect 用于记录日志,代码如下:

②添加订单获取用户信息:在添加订单方法 OrderServiceImpl.add(Order order) 中,从ThreadUserLog中获取用户会话,并填充给Order,代码如下

添加订单,日志输出可以看到调用添加订单和修改库存时,都记录了日志,并且获取了用户会话,效果如下:

加的订单数据库数据中也拥有用户信息,效果如下:

3 装饰着模式

定义:动态的向一个现有的对象添加新的功能,同时又不改变其结构。它属于结构型模式。

优点:装饰类和被装饰类可以独立发展,不会相互耦合,装饰模式是继承的一个替代模式,装饰模式可以动态扩展一个实现类的功能

缺点:多层装饰比较复杂。

3.1 装饰者模式实战

案例:结算价格计算,根据不同价格嵌套运算

在订单提交的时候,订单价格和结算价格其实是两码事,订单价格是当前商品成交价格,而结算价格是用户最终需要支付的金额,最终支付的金额并不是一成不变,它也并不是商品成交价格,能改变结算价格的因素很多,比如满100减10元,VIP用户再减5块。订单结算金额计算我们就可以采用装饰者模式。

3.1.2 装饰者模式价格运算实现

实现思路分析:

基础接口:创建接口 MoneySum ,该接口只用于定义计算订单金额的方法。

订单金额计算类:创建类 OrderPayMoneyOperation 实现订单金额的计算。

装饰者类:创建装饰者类 DecoratorMoneySum 供其他类扩展。

满100减10元价格计算:创建类 FullMoneySum 扩展装饰者类,实现满减价格计算。

VIP优惠10元价格计算:创建类 VipMoneySum ,实现VIP优惠计算。

支付金额计算:修改 OrderServiceImpl 的 add() 方法,添加订单金额以及订单支付金额的计算功能,代码如下:

测试效果:

测试数据中,我们选择购买1件商品,当前登录用户为王五,拥有5个金币,当前购买的商品id=1,商品单价是150元,满减100,VIP优惠5元,最终支付135元。

测试生成的订单如下:

不仅如此,我们可以随时撤掉满减和Vip优惠功能。

4 策略模式

定义:策略模式是对算法的包装,把使用算法的责任和算法本身分隔开,委派给不同的对象管理。策略模式通常把一系列的算法包装到一系列的策略类里面,作为一个抽象策略类的子类。

简单来说就是就定义一个策略接口,子类策略去实现该接口去定义不同的策略。然后定义一个环境(Context,也就是需要用到策略的对象)类,以策略接口作为成员变量,根据环境来使用具体的策略。

优点:

缺点:

4.1 策略模式实战

案例:结算价格计算,根据Vip不同等级进行运算

4.1.1 不同VIP优惠价格分析

用户在购买商品的时候,很多时候会根据Vip等级打不同折扣,尤其是在线商城中体现的淋漓尽致。我们这里也基于真实电商案例来实现VIP等级价格制:

4.1.2 代码实现

定义策略接口: Strategy

定义Vip0策略: StrategyVipOne

定义Vip1策略: StrategyVipTwo

定义Vip2策略: StrategyVipThree

定义Vip3策略: StrategyVipFour

定义策略工厂: StrategyFactory

等级策略配置:修改application.yml,将如下策略配置进去

等级控制:修改 UserHandler 添加等级属性

修改 UserHandlerShare 定义等级,代码如下:

装饰者模式中修改 VipMoneySum 的价格运算,代码如下:

测试:

5 工厂模式

案例:收银案例,根据不同支付方式,选择不同支付渠道

定义:定义一个创建产品对象的工厂接口,将产品对象的实际创建工作推迟到具体子工厂类当中。这满足创建型模式中所要求的“创建与使用相分离”的特点。

5.1 工厂模式实战

5.1.1 支付渠道选中分析

用户每次下单完成后,需要支付订单,支付订单会根据自身情况选择不同支付方式,后台服务会根据用户选中不同创建不同支付渠道的实例,这里创建支付渠道的实例可以采用工厂方法模式。

5.1.2 代码实现

工厂方法在SpringBoot中如果在用工厂的同时又出现了new,那绝对是一个败笔。在SpringBoot中,几乎所有对象

都可以直接交给Spring容器管理,它天然已经是一个工厂对象,因此在SpringBoot项目中用工厂模式,再频繁new对象反而不妥。那么工厂模式究竟怎么用在SpringBoot项目的支付场景呢?其实很简单,如果我们要选择一个支付渠道,而项目中有100种支付渠道,那这个时候无疑要写100个 @Autowired 注入100个支付渠道,并且需要做100种判断,这个时候我们可以用工厂模式取代我们判断,直接根据我们配置的映射关系从Spring容器中拿到对应支付渠道的实例,代码量将大大减少,这块是使用工厂的另一种妙用

支付接口: PayChannel 定义支付行为。

微信支付实现: WeixinPay 实现微信支付操作,这里只模拟。

支付宝支付实现: AliPay 实现支付宝支付,这里只模拟。

支付渠道映射配置:在 application.yml 中配置支付渠道映射,每次从前端传入支付ID即可从配置中获取支付渠道对应Spring容器中实例的id。

支付渠道获取工厂创建:创建 PayFactory 用于获取支付渠道的实例,我们这里通过映射的key获取Spring容器中实例的id值,然后从Spring容器中根据id获取对应实例,因此该工厂需要实现接口 ApplicationContextAware 来获取容器。

支付渠道调用实现:修改 PayServiceImpl 的 pay 方法,实现支付,代码如下:

测试:当我们选中支付渠道为1(微信支付)或者2(支付宝支付)的时候,都能争取获取对应的渠道实例。

6 状态模式

案例:订单不同状态,执行不同操作

定义:对有状态的对象,把复杂的“判断逻辑”提取到不同的状态对象中,允许状态对象在其内部状态发生改变时改变其行为。

优点

缺点

6.1 状态模式实战

6.1.1 状态模式案例分析

在电商案例中,订单状态每次发生变更,都要执行不同的操作,这里正好可以使用状态模式。当订单完成支付的时候,我们需要立即通知商家发货,当订单执行取消的时候,我们需要执行库存回滚,如果订单已支付,还需要执行退款操作,无论是通知商家发货还是执行库存回滚,都是有订单状态决定,因此这里可以使用状态模式来实现

我们可以先定义状态接口 State ,给状态接口实现两个不同的行为,分别是发货和回滚库存并退款,把该状态对象添加到订单内部作为成员属性,当订单的 state 状态改变时,触发执行不同的状态行为动作。

5.1.2 案例实现

状态接口定义: State 接口,用于定义更新状态对象,同时执行相关的行为。

发通知消息行为定义: SendMsgBehavior 用于实现给商家发送消息通知发货,这里模拟发送消息的行为。

库存回滚并退款:创建 ResetStoreBehavior ,用于实现订单库存回滚,并给用户退款操作,这里退款模拟相关行

为。

测试:

支付订单的时候,如果支付成功,我们调用 State 变更对应的状态行为,并执行相关行为,代码如下:

测试结果如下:

免责声明:本文内容来源于网络或用户投稿,龙泉人才网仅提供信息存储空间服务,不承担相关法律责任。若收录文章侵犯到您的权益/违法违规的内容,可请联系我们删除。
https://www.lqrc.cn/a/gongsi/60722.html

  • 关注微信
下一篇:暂无

猜你喜欢

微信公众号