Step4:策略模式再优化 看样子上面的代码好像没有什么问题了,但是Service层在调用策略的时候,不还是要通过if...else...来进行判断吗。只不过是从代码流程的切换变为了对策略调用的判断。 其实这也是可以解决的。首先我们要知道一点,就是外部肯定是知道它自己是要调用哪个策略的,所以我们只需要给每个策略编一个号,外...
1. 使用设计模式 策略模式 策略模式通过定义一系列算法,并将每个算法封装成一个类,使得它们可以相互替换,而不影响客户端调用。这样可以减少if else语句的数量,提高代码的灵活性。 // 策略接口interfaceStrategy{voidexecute();}// 具体策略实现类classConcreteStrategyAimplementsStrategy{@Overridepublicvoidexecute(){Sys...
策略模式消除 if else 代码存在过多假设 站在“现在”看“现在”,而不是站在“未来”看“现在” 不做超出功能的封装 结构化代码能够减少修改带来的错误 工厂模式 小结 TL;DR: 1.恰到好处的实现功能,不要给代码加入过多假设条件。 2.过早使用设计模式可能限制代码的灵活性,虽然是反直觉的,但是现实情况确实如此...
如果增加用户级别,只需要增加相应的类,如:SvipStrategy、SSvipStrategy等。这样 就不用修改getActualPriceWithStrategy()中的内容了,保证了这个方法的安全性。 测试代码如下: 测试结果: 代码语言:javascript 复制 getActualPriceWithStrategy()测试的真实价格为:90.0 其实上面我有使用到了设计模式中的策略模式,我将if-...
针对这种需要大量if...else的情况,可以使用设计模式中的策略模式来对代码进行优化和规范 策略模式实现 首先,定义一个抽象策略接口 判断type是否需要当前类来解析 解析文件内容 publicinterfaceType{/*** 当前type是否当前类型* @param type String* @return true or false*/booleanisMe(Stringtype);/*** 解析当前文...
if else 优化方案 方案1:策略模式 这个兄弟也说到了策略模式,策略模式介绍及实战看这篇: 别在再满屏的 if/ else 了,试试策略模式,真香!! 使用策略模式确实可以提升代码的优雅性,但也会存在以下问题: 如果是大量的 if else 分支,比如这 1 万个,那就会有 1 万个策略类,此时就会造成类膨胀,并且随着时间的...
在遇到if-else的分支业务逻辑比较复杂时,我们都习惯于将其抽出一个方法或者封装成一个对象去调用,这样整个if-else结构就不会显得太臃肿。 就上面例子,当回执的类型越来越多时,分支else if 就会越来越多,每增加一个回执类型,就需要修改或添加if-else分支,违反了开闭原则(对扩展开放,对修改关闭)。
第一步:使用策略模式优化if else里面的逻辑 第二步:使用工厂设计模式优化if 第三步:使用模板方法继续优化 回到顶部 背景 日常编码中我们经常遇到 很多if else的代码,比如 String name="";if("1A".equals(name)){ System.out.println("1111111AAAAAAAAA"); ...
下面是几种优化方案。 方案一:策略模式 使用策略模式确实可以提高代码的优雅性,但也会带来以下问题: 如果有大量 if-else 分支,比如这 10,000 个,那么将会产生 10,000 个策略类,导致类膨胀,随着时间推移,系统会变得越来越复杂和难以管理。 如果有多层嵌套的 if-else 语句,策略模式可能并不适用。