11丨软件设计的开闭原则：如何不修改代码却能实现需求变更？
该思维导图由 AI 生成，仅供参考
开闭原则
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文介绍了如何使用观察者模式和模板方法模式来实现软件设计的开闭原则。通过一个反面的例子展示了违反开闭原则的后果，以及如何使用策略模式和适配器模式来实现开闭原则。观察者模式和模板方法模式分别解决了一对多的对象依赖关系和按钮类型特有操作的问题，使得软件实体对扩展开放，对修改关闭。文章强调了抽象的重要性，指出实现开闭原则的关键在于抽象，并强调开闭原则是软件设计的核心原则。通过本文的讲解，读者可以了解如何利用设计模式来提高软件的灵活性和可扩展性，以及如何遵循开闭原则来指导和审视自己的设计。
《后端技术面试 38 讲》，新⼈⾸单¥59
全部留言(43)
- 最新
- 精选
山猫我同意老师通过这个例子简单的描述开闭原则。但如果项目初始就对button按钮需要进行这么复杂的设计，那么这个项目后期的维护成本也是相当之高。作者回复: 是否要使用各种设计模式设计一个非常灵活的程序，主要是看你的需求场景，而不是看项目的阶段。 如果你的场景就是需要这么灵活，就是要各种复用，应对各种变更，那么你一开始就应该这样设计。 如果你的场景根本不需要一个可复用的button，那么就不需要这样设计。 关键还是看场景。 但是场景也会变化，一开始不需要复用，但是后来又需要复用了，那么在在需要复用的第一个场景，就重构代码，而不是等将来维护困难局面hold不住了再重构。 ps 如果你习惯了这种灵活的设计，你会觉得这种设计并不复杂。对于软件开发而言，复杂的永远是业务逻辑，而不是设计模式。设计模式是可重复的，可重复的东西即使看起来复杂，熟悉了就会觉得很简单。 pps 看起来复杂的设计模式就是用来解决维护困难问题的，正确使用设计模式，看起来复杂了，其实维护简单了，因为关系和边界更清晰了，你不需要在一堆强耦合的代码里搅来搅去。真正维护成本高的其实是你所谓的简单的设计，牵一发动全身，稍不注意就是各种bug。 ppps 重要的话再说一次： 关键还是看场景。 没有银弹，没有一种必然就是好的设计方案，能理解场景的才是真·高手。
2019-12-163136- Paul Shan开闭原则是移除底层的if else，取而代之的是上层的类结构。不过，我个人以为一开始的if else, 甚至switch 也没什么不妥的，毕竟代码简单直接。引入了很多类，读代码也是负担，而且也很难预料到哪些修改是必要的。当if else数量多于一定的数目，再开始重构。 不知道李老师如何看待这种观点。
作者回复: 当你准备写第一个else的时候，就说明你的代码即将陷入僵化、牢固和脆弱，而且为将来的需求变更引入了一个糟糕的“设计模式”。 如果其他人接手你的代码，他有两个选择，要么继续写更多的else以应对需求变更；要么心理暗骂一声然后重构你的代码。你希望他选择哪个？
2019-12-1688 
虢國技醬“开闭原则可以说是软件设计原则的原则，是软件设计的核心原则，其他的设计原则更偏向技术性，具有技术性的指导意义，而开闭原则是方向性的，在软件设计的过程中，应该时刻以开闭原则指导、审视自己的设计：当需求变更的时候，现在的设计能否不修改代码就可以实现功能的扩展？如果不是，那么就应该进一步使用其他的设计原则和设计模式去重新设计。” 读的过程中一直有这种感觉：开闭原则可能是软件设计和实现时最重要的原则；果然和老师最后的总结一样。👍作者回复: 👍
2020-01-204
Winon请教老师，模板方法是否也是另外一种面向过程设计？是否在充血对象模型中，模板方法的使用会相对少？作者回复: 模板方法常和策略模式结合，为各种策略实现类提供模板和公共处理逻辑。 充血模型也需要策略和模板。
2020-07-052
yes我不是想找茬，我就想知道以上的代码怎么对说好的加“*” 和“#” 开闭作者回复: starButton = new Button(); starButton.addListener( new ButtonListener() { public void buttonPressed() { dialer.enterDigit(STAR); } } );
2020-01-272
唐二毛有一点想不通，在adapter里面还是需要判断呀？这并没有 达到老师说的 避免做switch/if判断的效果，而且判断的逻辑一点不少，还无端弄出这么多类，有必要非得这么做吗？作者回复: Adapter不需要判断，请看思考题
2019-12-191
whoami
老师的风格像酒剑仙，我们目标做李逍遥，悟。作者回复: 谢谢~
2021-04-09
布拉姆老师，怎么理解“不要过早优化”这句话呢？在设计的早期就利用设计模式实现软件的“开闭原则”有什么关系呢作者回复: “不要过早优化”是说，为潜在的或即将到来的问题而优化；设计时要遵循“开闭原则”是说，需求变化一定会到来，功能一定会扩展，所以要遵循各种基本设计原则。
2021-03-18
席席李老师，我尝试用上面的设计模式套用到我之前写的1400行代码中，策略模式的确分开了最开始的if判断，分成了三个类。 但我在需要使用他们的时候，又不得不使用if判断代码是否属于这三个类中的某一个，我并没有消灭if条件，但是我感觉这么用挺好的！ 还有我怀疑if真的能被消灭嘛？目前来讲，我只能做到拆分，无法消灭if作者回复: 用一个Factory返回策略类，把if的条件当做参数传给Factory，就不需要if了。 或者用一个map记录<if条件变量，策略对象>，从map中获得策略，也不需要if了。
2020-09-182
BestKF02有个问题： Button在优化到Adapter适配器的时候，token 怎么就不见了。没得token 怎么知道是取 DigitButtonDailerAdapter 还是 SendButtonDailerAdapter，这个片段突然缺失；老师有解答的地方吗？作者回复: 其实就是思考题的问题，建议参考代码思考一下
2020-02-21
