首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

OpenClosed原则仍然需要很多if-else

OpenClosed原则是面向对象设计中的一个重要原则,它强调软件实体(类、模块、函数等)应该对扩展开放,对修改关闭。换句话说,当需要添加新功能时,应该通过扩展现有代码来实现,而不是修改已有代码。

OpenClosed原则的核心思想是通过抽象和多态来实现代码的可扩展性和可维护性。通过定义抽象的接口或基类,可以使得代码对于新功能的扩展变得简单和灵活。而多态机制则允许在运行时根据实际对象的类型来调用相应的方法,从而实现不同对象的不同行为。

OpenClosed原则的优势包括:

  1. 可扩展性:通过扩展现有代码,可以方便地添加新功能,而不会影响已有功能的稳定性。
  2. 可维护性:由于不需要修改已有代码,因此维护代码变得更加简单和安全。
  3. 可复用性:通过定义抽象的接口或基类,可以使得代码更具通用性,提高代码的复用率。
  4. 可测试性:由于新功能的添加是通过扩展而不是修改已有代码,因此对于已有功能的测试可以保持不变,只需要针对新功能进行测试。

OpenClosed原则在软件开发中有广泛的应用场景,例如:

  1. 插件系统:通过定义插件接口,可以方便地添加新的插件来扩展系统功能。
  2. 框架设计:良好的框架设计应该遵循OpenClosed原则,以便开发者可以通过扩展框架来实现自定义功能。
  3. 设计模式:许多设计模式,如策略模式、装饰器模式等,都是基于OpenClosed原则的思想。

在腾讯云的产品中,与OpenClosed原则相关的产品包括:

  1. 云函数(Serverless):云函数是一种无服务器计算服务,可以根据实际需求动态扩展和收缩计算资源,实现代码的快速部署和扩展。 产品介绍链接:https://cloud.tencent.com/product/scf
  2. 云原生容器服务(TKE):云原生容器服务提供了弹性、高可用的容器集群管理能力,可以通过扩展容器实例来实现新功能的添加,同时保持已有容器的稳定运行。 产品介绍链接:https://cloud.tencent.com/product/tke

总结:OpenClosed原则是面向对象设计中的重要原则,通过对软件实体的扩展而不是修改来实现新功能的添加。它具有可扩展性、可维护性、可复用性和可测试性等优势。在腾讯云中,云函数和云原生容器服务是与OpenClosed原则相关的产品。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

Guava工具类简介

很多小伙伴的项目中已经引入了,但并没有使用,大家对于这个也是偶尔使用,但Guava中包涵了很多方面的类,例如集合、缓存、并发、IO等,今天笔者就带大家了解一下Guava内的一些类,希望对大家有所帮助。...System.out.println(multimap.get("a"));要注意,和BiMap的使用类似,使用get方法返回的集合也不是一个独立的对象,可以理解为集合视图的关联,对这个新集合的操作仍然会作用于原始的...范围Map RangeMap先看一个例子,假设我们要根据分数对考试成绩进行分类,那么代码中就会出现这样丑陋的if-else:public static String getRank(int score)...rangeMap.put(Range.closedOpen(0,60),"fail");rangeMap.put(Range.closed(60,90),"satisfa");rangeMap.put(Range.openClosed...如果我们需要对于一个条件信息判断 然后决定是否抛出异常,我们可以这么写 if(false){ throw new Exception("报错啦"); }通过Preconditions 可以简化为

33010

对复杂if-else代码块的优化方案

此外,上述switch-case方法还存在一个问题就是,一旦增加了新的消息类型,那么就需要不断的修改这个类的代码进行扩展。这在设计上来说不是一个很好的设计。这就不满足开闭原则。...那么只要我们后续添加的类型都始终满足这个逻辑的话,我们就可以使用反射的方式来优化这部分代码,使其符合开闭原则。...不过需要注意的是,上述方式仍然只能解决并列的分支判断问题。 1.5 用责任链模式处理复杂的嵌套关系 考虑到策略模式只能解决并列分支的问题,对解决分支嵌套的问题还是没有任何帮助。...责任链模式的链实际上是一个list对象,如果需要进入下一个嵌套,那么此处就不是写一个新的if-else,而是将这个新的if-else封装为一个对象,写在代码里面。...反正不难看出,对于if-else的处理,实际上有很多方式,但是我们需要注意的是避免对程序的过度设计,这样会造成代码的可读性变差。

99220
  • 为什么if-else会影响我的代码的复杂度

    其实这里使用设计模式并不复杂,主要就是 将条件抽出,形成条件类, 然后将条件存入集合中, 遍历这个集合即可 如果我们需要修改条件,只需要修改条件类,即步骤1即可。2、3步骤的代码我们不需要去管理。...其实规则引擎很强大,可以有更复杂的用途,我这里使用规则引擎其实和策略模式差不多,有人会考虑第三方API有风险,这个就需要团队判断了。...如果我们需要修改上面的条件逻辑,我相信编码者本人都会被这样的代码绕晕,更不用说后面接手的开发了。...从软件设计角度讲,代码中存在过多的 if-else 往往意味着这段代码违反了违反单一职责原则和开闭原则。因为在实际的项目中,需求往往是不断变化的,新需求也层出不穷。所以,软件系统的扩展性是非常重要的。...很多项目其实会有重构环节,我们在重构时思考我觉得也不晚。 关于减少复杂if-else的方法,推荐大家看看这些文章: “[if-else语句太多了?

    1.5K10

    如何优雅的用策略模式,取代臃肿的 if-else 嵌套,看这篇就够了

    经常听同事抱怨,订单来源又加了一种,代码又要加一层if-else判断,光判断订单来源的if-else就好几百行代码,代码我都不想看了,相信很多同行都有过这样的感受!...不少人说:Java的设计模式背了很多,可日常还不就是写if-else的业务,根本就不用到。其实不是用不到是没有用到合适的位置!...策略模式的使用场景: 针对同一问题的多种处理方式,仅仅是具体行为有差别时; 需要安全地封装多种同一类型的操作时; 同一抽象类有多个子类,而客户端需要使用if-else 或者 switch-case...,基本不需要改变原有的代码,符合开放封闭原则 避免使用多重条件选择语句,充分体现面向对象设计思想 策略类之间可以自由切换,由于策略类都实现同一个接口,所以使它们之间可以自由切换 每个策略类使用一个策略类...,符合单一职责原则 客户端与策略算法解耦,两者都依赖于抽象策略接口,符合依赖反转原则 客户端不需要知道都有哪些策略类,符合最小知识原则 缺点 策略模式,当策略算法太多时,会造成很多的策略类 客户端不知道有哪些策略类

    3.8K40

    CTO 写的代码,全网被吐槽,真是绝了

    通过改变: 可以减少if -else使得代码更加优雅 如果需要新增渠道,我们只需要在编写具体规则实现类并继承GeneralChannelRule抽象类,并在枚举类中新增的枚举,而不需要改动到原先的任何代码...这符合了开发封闭原则。 最后总结 以上是通过枚举来巧妙干掉if-else的方案,对于减少 if-else 还有很多有趣的解决方案(如:状态设计模式等),感兴趣的朋友去查阅相关的资料。...网友:cto代码抄百度 网友C:cto就写这样代码,你在忽悠我 网友D:很多CTO还没这水平 网友:策略模式了解一下 网友B:说白了就是个map B网友:那我不是有CTO之才 网友:这都能绝了,...不要逗我 网友:策略模式 网友:策略加工厂就不存违反开闭原则了 网友:抽象工厂也可以哦 网友:和用map有什么区别 网友:就这样? 网友:还有比这个更简单的 网友:为啥不用反射?...用枚举的话每增加一个渠道得改枚举和改if-else有啥区别? 网友:空引用了 网友:使用策略模式很好地解决了if-else问题,但是违背了软件设计的开闭原则,还需要进一步改进!

    41340

    策略模式不同,代码实现不同

    工厂模式调用方可以直接调用工厂实例的方法属性等,策略模式不能直接调用实例的方法属性,需要在策略类中封装策略后调用。 一个注重的是实例的生产,一个注重的是策略方法。...好了,这个时候再来看我们的代码,好像越来越复杂了,虽然用策略模式将具体的算法都抽离出来了,但是 if-else 的问题还是没有解决啊 思考一下,我们可不可以结合以下工厂模式,来去掉烦人的 if-else...策略模式优缺点 优点: 策略模式遵循开闭原则,实现代码的解耦合,用户可以在不修改原有系统的基础上选择算法或行为,也可以灵活地增加新的算法或行为。...算法的使用就和算法本身分开,符合单一职责原则 缺点: 客户端必须知道所有的策略类,并自行决定使用哪一个策略类 策略模式可能会造成系统产生很多具体策略类 总结 其实我们在工作中使用设计模式的时候,不需要被条条框框所束缚...,设计模式可以有很多变种,也可以结合几种设计模式一起使用,别忘了使用设计模式的初衷是什么,不要为了使用设计模式而使用设计模式。

    44930

    How to code like a pro in 2022 and avoid If-Else

    但是,许多高级开发人员都认为if...else...存在很多问题,而且我们在开发中也要尽量避免过度依赖if...else...。...语句并获得相同的结果,但这仍然不是最佳解决方案。...dogBreeds), () => eval("Cat", catBreeds) }; conditions.Any(c=> c()); 通过将动作移动到delegate(这是一个关键字,查阅很多文章发现并没有特别合适的汉语翻译...要记得: 如果维护你的代码的人仍然需要不断地调整代码,那他将变成一个知道你住在哪里的暴力精神病患者。...这篇文章说的并不是完全拒绝if-else语句,而是说要尽量避免if-else语句带来的冗杂和难维护性。如果借助if-else能够使得语句更有效率,那当然还是用使用。

    32210

    被迫重构代码,这次我干掉了 if-else

    一、策略模式的使用场景: 针对同一问题的多种处理方式,仅仅是具体行为有差别时; 需要安全地封装多种同一类型的操作时; 同一抽象类有多个子类,而客户端需要使用if-else 或者 switch-case...策略模式的优缺点 优点 易于扩展,增加一个新的策略只需要添加一个具体的策略类即可,基本不需要改变原有的代码,符合开放封闭原则 避免使用多重条件选择语句,充分体现面向对象设计思想 策略类之间可以自由切换,...由于策略类都实现同一个接口,所以使它们之间可以自由切换 每个策略类使用一个策略类,符合单一职责原则 客户端与策略算法解耦,两者都依赖于抽象策略接口,符合依赖反转原则 客户端不需要知道都有哪些策略类,符合最小知识原则...缺点 策略模式,当策略算法太多时,会造成很多的策略类 客户端不知道有哪些策略类,不能决定使用哪个策略类,这点可以通过封装common公共包解决,也可以考虑使IOC容器和依赖注入的方式来解决。...策略模式 将各个场景的逻辑剥离出来维护,同一抽象类有多个子类,需要使用if-else 或者 switch-case 来选择具体子类时,建议选策略模式,他的缺点就是会产生比较多的策略类文件。

    49430

    实例告诉你如何把 if-else 重构成高质量代码!

    程序员想必都经历过这样的场景:刚开始自己写的代码很简洁,逻辑清晰,函数精简,没有一个 if-else,可随着代码逻辑不断完善和业务的瞬息万变:比如需要对入参进行类型和值进行判断;这里要判断下对象是否为...虽然我们都很不情愿写出满屏 if-else 的代码,可逻辑上就是需要特殊判断,很绝望,可也没办法避免啊。 其实回头看看自己的代码,写 if-else 不外乎两种场景:异常逻辑处理和不同状态处理。...重构 if-else 时,心中无时无刻把握一个原则: 尽可能地维持正常流程代码在最外层。 意思是说,可以写 if-else 语句时一定要尽量保持主干代码是正常流程,避免嵌套过深。...0:getBaseSpeed(_voltage); 20    } 21} 可以看到,使用多态后直接没有了 if-else,但使用多态对原来代码修改过大,需要一番功夫才行。...这些资料的内容都是面试时面试官必问的知识点,篇章包括了很多知识点,其中包括了有基础知识、Java集合、JVM、多线程并发、spring原理、微服务、Netty 与RPC 、Kafka、日记、设计模式、Java

    59300

    前端day09-JS学习笔记

    }else{ 条件不成立时需要执行的代码 } if-else结构注意点 if大括号中的代码与else大括号的代码只会执行一个,不会同时执行 if-else语句的作用主要就是为了提高代码的运行效率...,虽然可以用两个if语句来代替if-else语句,但是两个if语句需要判断两次,而if-else需要判断一次 1.3-if-else if-else多分支结构 if(条件1){ 条件1成立时需要执行的代码...: if-else if -else结构中必须以if开头,中间的else if可以是多个,末尾的esle可以省略(一般都不会省略) if-else if-else语句中所有的大括号中的代码只会执行其中一个...1.原则上,三种分支结构语句之间可以互转,只不过每一种分支结构语句适用场景不一样 2.if分支结构:适合条件判断 最常用:if-else 两种互斥条件判断 3.switch-case 适合做固定值匹配...3.今天学的代码调试非常的简单,只要记住代码调试的这几个按钮的作用即可,后面还会学到很多的代码调试技巧。

    87800

    6个实例详解如何把if-else代码重构成高质量代码

    程序员想必都经历过这样的场景:刚开始自己写的代码很简洁,逻辑清晰,函数精简,没有一个if-else, 可随着代码逻辑不断完善和业务的瞬息万变:比如需要对入参进行类型和值进行判断;这里要判断下对象是否为null...虽然我们都很不情愿写出满屏if-else的代码,可逻辑上就是需要特殊判断,很绝望,可也没办法避免啊。 其实回头看看自己的代码,写if-else不外乎两种场景:异常逻辑处理和不同状态处理。...重构if-else时,心中无时无刻把握一个原则: 尽可能地维持正常流程代码在最外层。 意思是说,可以写if-else语句时一定要尽量保持主干代码是正常流程,避免嵌套过深。...0:getBaseSpeed(_voltage); } } 可以看到,使用多态后直接没有了if-else,但使用多态对原来代码修改过大,需要一番功夫才行。最好在设计之初就使用多态方式。...针对条件型代码重构把握一个原则: 尽可能地维持正常流程代码在最外层,保持主干流程是正常核心流程。

    1.2K10

    因为if-else,而被罚款了1000!!

    If-Else 转换为字典,完全避免 If-Else 假设您需要执行一些操作,这些操作将根据某些条件进行选择,我们知道以后必须添加更多操作。 ? 也许有人倾向于使用久经考验的 If-Else。...作为初级开发人员,您可能会倾向于通过添加额外的 If-Else(即 else-if)语句来做到这一点。 举这个说明性的例子。在这里,我们需要将 Order 实例显示为字符串。...在此阶段使用 If-Else 并不是什么大问题,如果我们可以轻松替换其他,只要如前所述即可。 ? 知道我们需要扩展应用程序的这一部分,这种方法绝对是不可接受的。...上面的代码不仅违反了"打开/关闭"原则,而且阅读得不好,还会引起可维护性方面的麻烦。 正确的方法是遵循 SOLID 原则的方法,我们通过实施动态类型发现过程(在本例中为策略模式)来做到这一点。...我只显示将替换 If-Else 示例的确切部分。如果要查看所有涉及的对象,请查看此要点。 ? 让我们快速浏览一下代码。方法签名保持不变,因为调用者不需要了解我们的重构。

    55310

    我们公司是如何把项目中的2100个if-else彻底干掉的!

    下面的示例很好地说明了当您被认为If-Else很棒时会发生什么。 ? 只需删除else`块即可简化此过程。 ? 看起来更专业吧? 您会经常发现,实际上根本不需要其他块。...4.将If-Else转换为字典—完全避免If-Else 假设您需要执行一些操作,这些操作将根据某些条件进行选择,我们知道以后必须添加更多操作。 ? 也许有人倾向于使用久经考验的If-Else。...作为初级开发人员,您可能会倾向于通过添加额外的If-Else(即else-if)语句来做到这一点。 举这个说明性的例子。在这里,我们需要将Order实例显示为字符串。...在此阶段使用If-Else并不是什么大问题,如果我们可以轻松替换其他,只要如前所述即可。 ? 知道我们需要扩展应用程序的这一部分,这种方法绝对是不可接受的。...上面的代码不仅违反了"打开/关闭"原则,而且阅读得不好,还会引起可维护性方面的麻烦。 正确的方法是遵循SOLID原则的方法-我们通过实施动态类型发现过程(在本例中为策略模式)来做到这一点。

    94310

    替换If-Else的5种方法从入门到高级示例

    4、将If-Else转换为字典—完全避免If-Else 假设您需要执行一些操作,这些操作将根据某些条件进行选择,我们知道以后必须添加更多操作。 也许有人倾向于使用久经考验的If-Else。...作为初级开发人员,您可能会倾向于通过添加额外的If-Else(即else-if)语句来做到这一点。 举这个说明性的例子。在这里,我们需要将Order实例显示为字符串。...在此阶段使用If-Else并不是什么大问题,如果我们可以轻松替换其他,只要如前所述即可。 知道我们需要扩展应用程序的这一部分,这种方法绝对是不可接受的。...上面的代码不仅违反了"打开/关闭"原则,而且阅读得不好,还会引起可维护性方面的麻烦。 正确的方法是遵循SOLID原则的方法-我们通过实施动态类型发现过程(在本例中为策略模式)来做到这一点。...我只显示将替换If-Else示例的确切部分。如果要查看所有涉及的对象,请查看此要点。 让我们快速浏览一下代码。 方法签名保持不变,因为调用者不需要了解我们的重构。

    4.8K30

    CTO写的代码,真是绝了!

    图片来自 Pexels 本文通过一个简单的例子来展示如何通过枚举巧妙地干掉 if-else,使代码看起来更佳优雅。...a.当我们需要新增新的渠道的时候,需要对 main 方法中的逻辑进行修改调整。 这违背了设计模式中的开放封闭规则。开放封闭原则的核心的思想是软件实体是可扩展,而不可修改的。...通过改变: 可以减少 if-else 使得代码更加优雅。...如果需要新增渠道,我们只需要在编写具体规则实现类并继承 GeneralChannelRule 抽象类,并在枚举类中新增的枚举,而不需要改动到原先的任何代码。这符合了开发封闭原则。...最后 以上是通过枚举来巧妙干掉 if-else 的方案,对于减少 if-else 还有很多有趣的解决方案(如:状态设计模式等),感兴趣的朋友去查阅相关的资料。

    31120

    编写 if 时不带 else,你的代码会更好!

    4 将 If-Else 转换为字典—完全避免 If-Else 假设您需要执行一些操作,这些操作将根据某些条件进行选择,我们知道以后必须添加更多操作。 也许有人倾向于使用久经考验的 If-Else。...知道我们以后需要添加新的操作后,我们可以将 If-Else 重构为字典。 可读性已大大提高,并且可以更轻松地推断出该代码。 “ 注意,仅出于说明目的将字典放置在方法内部。...在此阶段使用 If-Else 并不是什么大问题,如果我们可以轻松替换其他,只要如前所述即可。 知道我们需要扩展应用程序的这一部分,这种方法绝对是不可接受的。...上面的代码不仅违反了 "打开 / 关闭" 原则,而且阅读得不好,还会引起可维护性方面的麻烦。...正确的方法是遵循 SOLID 原则的方法 - 我们通过实施动态类型发现过程(在本例中为策略模式)来做到这一点。

    60330

    教你用策略模式解决多重if-else

    下面举个例子,使用策略模式解决多重if-else的代码结构。想学习更多的设计模式的实战经验,那就点个关注吧,谢谢大佬。...使用if-else 假设我们要开发一个支付接口,要对接多种支付方式,通过渠道码区分各种的支付方式。...在设计模式六大原则中,其中一个原则叫做开闭原则,对扩展开放,对修改关闭,应尽量在不修改原有代码的情况下进行扩展。 基于上面提到的开闭原则,我们可以使用策略模式进行重构。...突然间代码就显得清爽很多了! 小伙伴们看到这里,get到新的技能了吗?...假设需要增加新的支付方式,就不需要再使用else if 去判断,而是在枚举中定义一个新的枚举对象,然后再增加一个策略实现类,实现对应的方法,那就可以很轻松地扩展。也实现了开闭原则

    1.3K10

    来吧,用设计模式来干掉 if-else

    就上面例子,当回执的类型越来越多时,分支else if 就会越来越多,每增加一个回执类型,就需要修改或添加if-else分支,违反了开闭原则(对扩展开放,对修改关闭) 策略模式+Map字典 我们知道,...在上述场景中,我们可以把if-else分支的业务逻辑抽取为各种策略,但是不可避免的是依然需要客户端写一些if-else进行策略选择的逻辑,我们可以将这段逻辑抽取到工厂类中去,这就是策略模式+简单工厂,代码如下...如果要使得程序符合开闭原则,则需要调整ReceiptHandleStrategyFactory中处理策略的获取方式,通过反射的方式,获取指定包下的所有IReceiptHandleStrategy实现类,...在责任链模式里,很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递,直到链上的某一个对象决定处理此请求。...结构也被我们消除了,每当新来了一种回执,只需要添加IReceiptHandler实现类并修改ReceiptHandlerContainer处理者容器即可,如果要使得程序符合开闭原则,则需要调整ReceiptHandlerContainer

    3.5K21

    使用策略模式消除if else

    conditionB) { 逻辑2 } else if (conditionC) { 逻辑3 } else { 逻辑4 } 这种代码虽然写起来简单,但是很明显违反了面向对象的 2 个基本原则...: 单一职责原则(一个类应该只有一个发生变化的原因):因为之后修改任何一个逻辑,当前类都会被修改 开闭原则(对扩展开放,对修改关闭):如果此时需要添加(删除)某个逻辑,那么不可避免的要修改原来的代码 因为违反了以上两个原则...,尤其是当 if-else 块中的代码量比较大时,后续代码的扩展和维护就会逐渐变得非常困难且容易出错 if-else 不超过 2 层,块中代码 1~5 行,直接写到块中,否则封装为方法 if-else...超过 2 层,且块中代码超过 3 行,尽量使用策略模式 下面是PHP策略模式的demo,需求是当需要发送各种通知的时候 , 比如发送短信 ,发送邮件 , 发送微信通知 等等 ,可以拆分成一个个策略 <?

    85330
    领券