策略模式+工厂模式+枚举类优化代码 背景 业务需要将多数据源数据导入如下图: 解释一下,比如Mysql表中有name、age字段,现在业务需要,要将name字段所有记录转存到ES ,也会对name字段进行字段名无意义化(后台可以查到配置对应关系)。 设计 需要考虑可扩展性...
所有的策略类都需要对外暴露(使用的人必须了解使用策略,这个就需要其他模式来补充,比如工厂模式、代理模式)3|0三、代码示例3|11.定义共同的方法和行为package com.ultiwill.strategy; public interface PayStrategy { /** * 共同的行为方法 * @return */ String toPayHtml(); } ...
@GetMapping("test1")publicStringgetTests(String eventType){ValidatorContext validator=newValidatorContext(ValidatorStrategy.XML);validator.runValidation("XML content");} 方法三:枚举+工厂 一、建造枚举类 packagecom.ultiwill.strategy.enums;importorg.apache.commons.lang.StringUtils;publicenumPayEnumStrategy{/...
2. 工厂模式(Factory Pattern) 工厂模式提供了一种创建对象的最佳方式。使用工厂模式,当我们不知道最终创建哪个对象时,可以动态地选择创建对象。 示例 假设我们有一个图形绘制系统,不同的图形需要不同的绘制方法。 // 定义产品接口 interface Shape { void draw(); } // 具体产品类 class Circle implements Shape...
三、基于枚举的策略模式 四、基于工厂的策略模式 一、为什么讲策略模式 策略模式,应该是工作中比较常用的设计模式,调用方自己选择用哪一种策略完成对数据的操作,也就是“一个类的行为或其算法可以在运行时更改” 我个人的理解是 将一些除了过程不同其他都一样的函数封装成策略,然后调用方自己去选择想让数据执行什么...
策略模式+工厂模式(反射)+枚举代替 大量 if..else if.. 实际项目中我们经常碰到需要使用if…else…if的分支判断这种情况。 这种写法带来一些弊端。 一旦分支多太多,逻辑复杂,会导致代码十分冗长,增加阅读难度。 如果需要增加或减少分支,需要改动if…elseif,增大因代码改动而出错的风险。
这些策略如何在合适的时机使用呢?在讲策略模式的时候,我们是借助一个环境类,持有抽象策略的引用,然后初始化该环境类的时候,传进来一个具体策略对象赋值给抽象策略。 这次讲解的是整合工厂模式,使用静态工厂方法,根据入参来从内存中找到早已初始化好的具体策略对象,即枚举中的实例对象。
工厂模式是解耦对象的创建和使用,观察者模式是解耦观察者和被观察者。策略模式跟两者类似,也能起到解耦的作用,不过,它解耦的是策略的定义、创建、使用这三部分。 2 实现 这里实现一个计算订单价格的策略,商品可能会做各种活动,每种活动折扣都不一样,这里通过策略模式实现,代码简洁,以后增加活动的时候不需要修改原有...
2、使用工厂模式+策略设计模式,同时结合SpringBoot注解选择不同的策略,实现不同的业务逻辑。 代码示例 定义枚举 @AllArgsConstructor@GetterpublicenumSaleOrderEnum{SHOP_SALE_ORDER("10001","店铺业务零售单"),SUPPLY_SALE_ORDER("10002","供应链直销单"),;privatestaticfinalMap<Long,SaleOrderEnum>ORDER_MAP=newHa...
2. 可读性:通过使用策略和工厂而不是 if-else 块,使代码更易于理解和管理。 3. 可维护性:采用策略和工厂模式后,可以修改代码而不影响其他部分。 结论如下:从混乱到清晰 如果你正在开发一个正在增长的项目,不要使用if-else语句。策略模式和工厂模式是让代码更清晰、模块化且易于维护的完美方案。