OCP — 原则、对扩展开放和对修改关闭

什么是OCP（开闭原则）？

OCP（开闭原则） — 对扩展开放、对修改关闭的原则。类、模块和函数的设计应使新行为可以在不修改其源代码的情况下添加。扩展通过继承、组合或替换接口实现来实现。

Bertrand Meyer在《Object-Oriented Software Construction》（1988）一书中首次通过继承描述了OCP：基类保持不变，子类扩展其行为。由Robert C. Martin提出的现代OCP解释基于多态和接口：使用抽象契约代替继承。

两种方法之间的差异显著。继承在基类和派生类之间创建了紧密耦合。接口和组合提供了灵活性：实现可以在不修改客户端代码的情况下被替换。现代OCP — 是关于抽象，而不是继承。

多态作为OCP的基础

多态OCP使用抽象类或接口来定义契约。客户端代码与抽象交互，而不了解具体实现。新功能通过创建一个实现相同接口的新类来添加 — 无需对现有代码进行任何更改。这使得系统对变化具有抵抗力，并且对于扩展具有可预测性。

在移动开发中，这种方法无处不在：策略模式允许通过公共接口替换算法（图像压缩、缓存、身份验证）。添加新策略不需要修改使用它的代码。

如何实现开放和关闭原则

OCP的实现始于将可变行为分离到抽象中。如果代码中存在检查对象类型的switch结构或if-else链 — 这是应用OCP的信号。每个条件分支在扩展时都可能需要添加新分支。

根据OCP的重构过程包括三个步骤：识别可变方面（可以扩展的内容），将其分离到接口或抽象类中，重写客户端代码以使用抽象而非具体类。之后，新功能在不修改客户端的情况下添加。

重要说明：对修改关闭并非绝对。如果修改需求涉及抽象本身或契约 — 更改是不可避免的。OCP保护的是实现中的更改，而不是契约中的更改。良好的设计假设契约是稳定的，而实现是可变的。

在评估架构与OCP的兼容性时，查看扩展点是有帮助的。开发者为新类型添加if-else或switch的每个点 — 都是抽象的候选对象。按照OCP设计的系统具有可预测的扩展点：带有文档说明的接口，注明“实现此接口以添加新类型”。在Android中，这样的例子是与ViewModelProvider.Factory一起使用的工厂模式 — 添加新的ViewModel类型不需要修改现有工厂。

OCP的策略和模式

最有效的模式用于在移动开发中遵守OCP，包括Strategy、Template Method、Decorator和Factory。每种模式通过不同的面向对象设计机制，解决了在不修改现有代码的情况下扩展行为的问题。

策略模式允许通过公共接口即时替换算法。在iOS开发中，策略用于动画和表单验证。模板方法模式在基类中定义算法的骨架，子类覆盖步骤 — 适用于具有共同结构但内容不同的屏幕。

装饰器模式在不修改对象类的情况下动态地向对象添加行为。在Android中，装饰器用于将Repository包装在缓存或日志记录层中。工厂方法模式通过接口创建对象，允许子类决定实例化哪个类 — 符合OCP的依赖创建基础。

为移动项目选择策略

模式的选择取决于被扩展行为的稳定性。当算法完全替换时，策略模式最佳。模板方法 — 当结构固定但步骤可变时。装饰器 — 当扩展对客户端必须透明时。对于Android和iOS中的大多数场景，策略模式 + 依赖注入就足够了。

在没有OCP的情况下应用这些模式在技术上是可行的，但失去了意义。正是OCP证明了为什么我们要引入额外的抽象层：使系统无需重写现有代码即可增长。

移动应用中的OCP示例

让我们看一个Android示例 — 支付处理。没有OCP，每个新的支付系统都需要修改处理类。有了OCP，可以在不修改现有代码的情况下添加新的接口实现。

// 违反OCP：switch需要为新系统进行修改
class BadPaymentProcessor {
    fun process(type: String) {
        when (type) {
            "card" -> // 处理银行卡
            "paypal" -> // 处理PayPal
        }
    }
}

// 兼容OCP的设计
interface PaymentMethod {
    fun pay(amount: Double)
}

class CardPayment : PaymentMethod {
    override fun pay(amount: Double) { }
}

class PayPalPayment : PaymentMethod {
    override fun pay(amount: Double) { }
}

// 新系统 — 新类，无需修改现有代码
class ApplePayPayment : PaymentMethod {
    override fun pay(amount: Double) { }
}

iOS示例 — 文本字段验证，通过Swift协议展示相同的逻辑：

// 兼容OCP的验证
protocol ValidationRule {
    func validate(_ input: String) -> Bool
}

struct EmailRule: ValidationRule {
    func validate(_ input: String) -> Bool {
        return input.contains("@")
    }
}

struct PhoneRule: ValidationRule {
    func validate(_ input: String) -> Bool {
        return input.count == 11
    }
}

// 添加新规则不需要修改验证器代码
struct PasswordRule: ValidationRule {
    func validate(_ input: String) -> Bool {
        return input.count >= 8
    }
}

OCP的关键优势在这些示例中：添加ApplePay或PasswordRule不需要修改现有类。代码水平扩展 — 通过新文件，而不是修改旧文件。这降低了回归风险并加速了新功能的实现。

违反OCP的典型错误

最常见的违规 — 基于对象类型的switch或when结构。每次添加新类型时，都必须找到代码中所有此类switch并添加新分支。遗漏的switch — 一个在编译阶段难以发现的运行时错误。

在移动开发中，使用巨大的枚举类且其方法依赖于枚举值时会违反OCP。添加新的枚举元素需要修改整个项目中的每个switch。替代方案 — 通过接口实现多态，其中每个类型实现自己的行为。

另一个典型违规 — 上帝适配器：通过if-else处理不同单元格类型的RecyclerView.Adapter（Android）或UITableViewDataSource（iOS）。每个新的单元格类型都需要扩展适配器。解决方案 — 具有公共bind方法的多态ViewHolder，其中每个单元格类型负责自己的显示。

如何避免违反OCP

预防措施包括：放弃基于类型的switch，改用多态；通过接口进行依赖注入；应用工厂模式根据配置创建对象。分析代码中的“类型开关” — 面向OCP的团队中代码审查的强制部分。

重构现有的OCP违规通过Replace Conditional with Polymorphism进行：条件的每个分支成为实现公共接口的独立类。客户端代码被重写为与接口交互，具体实现通过工厂或DI容器提供。

重要的是要理解，OCP和多态并不能解决所有扩展问题。如果架构选择不正确，添加新功能将不仅需要修改实现，还需要修改契约。良好的架构预测扩展方向，并恰好在这些点放置抽象。项目存在时间越长、特定模块的需求变化越频繁，对OCP的投资回报就越大。