重复代码VS开闭原则：求教开闭原则的适用场景与时机

一、先把开闭原则的适用时机说透 #

咱先把你纠结的开闭原则（OCP）掰明白：它的核心就是对扩展开放，对修改关闭——简单说就是，别随便改已经跑稳的老代码，要加新功能就通过继承、实现接口这类扩展方式来搞。

那什么时候该用它？给你列几个最常见的场景：

• 当你接手的模块明确未来要加新功能，而且当前修改老代码容易牵一发而动全身（比如多人维护的核心业务类）
• 业务规则经常变的地方，比如电商的优惠计算、物流计费逻辑——每次改规则都动老代码，早晚出问题
• 要复用现有核心逻辑，但需要添加差异化功能的时候，比如不同类型的支付方式，核心的订单校验逻辑一样，但支付流程不一样，这时候用扩展就比改原类靠谱

二、结合你遇到的场景分析 #

你说同事想在已有特定职责的类里加不相关的新方法？这首先就违反了单一职责原则，同时也踩了开闭原则的坑。原类的职责本来是明确的，硬塞不相关的方法进去，会让它变得臃肿，以后别人维护的时候，根本搞不清这个类到底管啥，而且改原类的风险极高——万一不小心影响了原有功能，锅谁背？

你的思路是对的：通过继承原类，在新类里加这个方法，完美符合开闭原则——原类啥也不用改（对修改关闭），新功能通过扩展实现（对扩展开放），而且职责划分清晰，原类还是管它原来的事，新类负责新增的功能，后续维护起来也省心。

三、顺便提下代码重复和开闭原则的关联 #

虽然你对代码重复理解得透，但还是补一句：开闭原则其实是避免代码重复的利器。比如你把核心逻辑抽在基类里，子类只扩展差异化部分，就不用在每个新类里复制粘贴相同的逻辑，既减少重复，又方便统一修改核心逻辑。

四、如果和同事沟通有障碍，试试举例子 #

要是同事不理解，你可以拿具体场景举例：比如原类是UserAuthenticator（只负责用户登录校验），现在要加生成用户登录日志的功能，这功能明显不属于认证职责，你总不能把日志方法塞到UserAuthenticator里吧？这时候新建LoggingUserAuthenticator继承原类，在新类里加日志逻辑，原类的认证功能丝毫不影响，以后要改日志逻辑也只动新类，多清爽。

内容的提问来源于stack exchange，提问作者Eddy Bayonne