SOLID设计原则:开闭原则

简介: 本文通过电商库存系统的例子,详细介绍了开闭原则(OCP)的实现方法,强调“对扩展开放,对修改关闭”的核心理念。文中展示了如何利用继承、接口和多态性避免频繁修改代码,并通过策略模式和装饰器模式等设计模式实现灵活扩展。通过具体案例分析,帮助读者理解开闭原则的应用场景与实践技巧,提升代码质量和可维护性。文章还鼓励开发者在日常业务开发中应用设计模式,以提高技术水平。

你好,我是猿java。

真实工作中,你是否是这样操作过:一个需求过来,把原来的代码改一遍,再一个需求过来,又把上一个需求的代码改一遍,很多重复的工作还是在日复一日的重复,有什么好的办法改善吗?

相信有经验的小伙伴一定听过:对扩展开放,对修改关闭。那么,你知道这句话的真正含义吗?今天我们就来聊聊开闭原则到底是怎么实现的。

什么是开闭原则?

开放封闭原则,英文是:Open–closed principle, 简称OCP,是该原则是 Bertrand Meyer 在1988年提出的,最后被 Robert C. Martin收录到 SOLID原则,开闭原则指出:

Software entities should be open for extension, but closed for modification.

软件实体应该对扩展开放,对修改关闭。

如何实现开闭原则?

"对扩展开放,对修改关闭",如何理解呢?我们先看一个案例,如下图,给出了电商领域库存系统库存变更的简易模型图,库存系统接收外部系统库存变更事件,然后对数据库中的库存进行修改。
stock.png

面对这个业务需求,很多人的代码会写出这样

public class Stock {
   
    public void updateStock(String event){
   

        if("outOfStock" == event){
   
            // todo 出库事件   库存操作

        }else if("warehousing" == event){
   
            // todo 入库事件   库存操作

        }
    }
}

这时,新的需求来了:WMS仓储系统内部会产生盘点事件(盘盈/盘亏),这些事件会导致变更库存。于是,代码就会发展成下面这样

public class Stock {
   

    public void updateStock(String event){
   

        if("outOfStock" == event){
   
            // todo 出库事件   库存操作

        }else if("warehousing" == event){
   
            // todo 入库事件   库存操作

        }else if("panSurplus" == event){
   
            // todo 盘盈事件   库存操作

        }else if("loss" == event){
   
            // todo 盘亏事件   库存操作
        }
    }
}

很显然,上述代码的实现,每来一个需求,就需要修改一次代码,在方法中增加一个 else if分支,因此 Stock类就一直处于变更中,不稳定。

有没有什么好的办法,可以使得这个代码不用被修改,但是又能够灵活的扩展,满足业务需求呢?

这个时候我们就要搬出 java的三大法宝:继承,实现,多态

我们发现整个业务模型是:事件导致库存变更。所以,能不能把事件抽离出来?把它抽象成一个接口,代码如下:

model.png

public interface Event {
   
    void updateStock(String event);
}

每种事件对应一种库存变更,抽象成一个具体的实现类,代码如下

入库事件

public class WarehousingEvent implements Event {
   
    public void updateStock(String event){
   
        // 业务逻辑
    }
}

出库事件

public class OutOfStockEvent implements Event {
   
    public void updateStock(String event){
   
        // 业务逻辑
    }
}

xxx事件

public class XXXEvent implements Event {
   
    public void updateStock(String event){
   
        // 业务逻辑
    }
}

最后,Stock类中 updateStock()库存变更逻辑就可以抽象成下面这样:


public class Stock {
   
    public void updateStock(String event){
   
        // 根据事件类型获取真实的实现类
        Event event = getEventInstance(event);
        // 库存变更操作
        event.updateStock();
    }
}

经过抽象、分离和改造之后,Stock.updateStock()类就稳定下来了,再也不需要每增加一个事件就需要增加一个 else if分支处理,这种抽象带来的好处也是很明显的:每次有新的库存变更事件,只需要增加一个实现类,其他的逻辑都不需要更改,当库存事件无效时只需要把实现类删除即可。

开闭原则是常见方式

在Java编程中,遵循开闭原则的常见方式有:使用抽象类和接口、使用策略模式、使用装饰器模式等。

抽象类和接口

抽象类和接口是 Java中实现 开闭原则的基础,通过定义抽象类或接口,程序员可以在不修改已有代码的情况下,通过继承或实现来扩展新功能。因此,我们强烈建议:面向接口编程。

策略模式

策略模式是一种行为设计模式,允许在运行时选择算法的实现,策略模式通过定义一系列算法,并将每个算法封装在独立的类中,使得它们可以相互替换。

在上面的示例讲解中,其实使用的就是策略模式,当后期有其他的库存事件时,我们只需要添加扩展类,而无需修改现有的代码。

装饰器模式

装饰器模式是一种结构设计模式,允许向一个对象动态添加行为。装饰器模式通过创建一个装饰器类来包装原始类,从而增加新的功能。示例代码:

// 定义一个接口
public interface Coffee {
   
    String getDescription();
    double getCost();
}

// 实现接口的具体类
public class SimpleCoffee implements Coffee {
   
    @Override
    public String getDescription() {
   
        return "Simple Coffee";
    }

    @Override
    public double getCost() {
   
        return 5.0;
    }
}

// 创建装饰器抽象类
public abstract class CoffeeDecorator implements Coffee {
   
    protected Coffee decoratedCoffee;

    public CoffeeDecorator(Coffee coffee) {
   
        this.decoratedCoffee = coffee;
    }

    @Override
    public String getDescription() {
   
        return decoratedCoffee.getDescription();
    }

    @Override
    public double getCost() {
   
        return decoratedCoffee.getCost();
    }
}

// 实现具体的装饰器类
public class MilkDecorator extends CoffeeDecorator {
   
    public MilkDecorator(Coffee coffee) {
   
        super(coffee);
    }

    @Override
    public String getDescription() {
   
        return decoratedCoffee.getDescription() + ", Milk";
    }

    @Override
    public double getCost() {
   
        return decoratedCoffee.getCost() + 1.5;
    }
}

public class SugarDecorator extends CoffeeDecorator {
   
    public SugarDecorator(Coffee coffee) {
   
        super(coffee);
    }

    @Override
    public String getDescription() {
   
        return decoratedCoffee.getDescription() + ", Sugar";
    }

    @Override
    public double getCost() {
   
        return decoratedCoffee.getCost() + 0.5;
    }
}

// 客户端代码
public class CoffeeShop {
   
    public static void main(String[] args) {
   
        Coffee coffee = new SimpleCoffee();
        System.out.println(coffee.getDescription() + " $" + coffee.getCost());

        coffee = new MilkDecorator(coffee);
        System.out.println(coffee.getDescription() + " $" + coffee.getCost());

        coffee = new SugarDecorator(coffee);
        System.out.println(coffee.getDescription() + " $" + coffee.getCost());
    }
}

在这个示例中,Coffee接口定义了获取描述和成本的方法,SimpleCoffee类实现了这个接口。CoffeeDecorator类是一个抽象类,实现了 Coffee接口,并持有一个 Coffee对象。MilkDecorator和SugarDecorator类分别继承了CoffeeDecorator类,并扩展了其功能。如果我们需要增加新的装饰器,只需要继承 CoffeeDecorator类并实现其方法即可,而无需修改现有的代码。

总结

本文通过一个电商中库存实例,演示了开闭原则的整个抽象和实现过程,并给出了开闭原则最常用的 3种实现方式。

开闭原则的核心是对扩展开放,对修改关闭,因此,当业务需求一直需要修改同一段代码时,我们就得多思考代码修改的理由是什么?它们之间是不是有一定的共同性?能不能把这些变更点分离出来,通过扩展来实现而不是修改代码?

其实在业务开发中还有很多类似的场景,比如:电商系统中的会员系统,需要根据用户不同的等级计算不同的费用;机票系统,根据用户不同的等级(普通,白金用户,黄金用户...)提供不同的售票机制;网关系统中,根据不同的粒度(接口,ip,服务,集群)来实现限流;

可能有小伙伴会反驳,业务场景有类似的场景,但是逻辑简单,几个 if-else就搞定了,没有必要去搞这么复杂的设计。

本人建议:功夫在平时,功夫在细节。

很多人总抱怨业务开发技术成长慢,特别是对于初级程序员,但是大部门人的起点都是业务的 CRUD,如果能在业务 CRUD过程中想办法"挖掘"某些
设计模式,通过这种长期的刻意练习,量变产生质变,慢慢就能领会这些经典设计原则的奥妙,终有一天也能写出让人赏心悦目的代码。

学习交流

如果你觉得文章有帮助,请帮忙转发给更多的好友,或关注:猿java,持续输出硬核文章。

目录
相关文章
|
2月前
|
Java 关系型数据库
SOLID设计原则:接口隔离原则
本文探讨接口隔离原则(ISP),它是SOLID原则之一,强调不应强迫客户依赖不使用的方法。通过将接口拆分为多个具体接口,可以避免不必要的依赖,提高系统灵活性。接口隔离原则不同于单一职责原则,前者关注接口设计,后者关注类的职责划分。合理应用ISP可以提升代码质量,但在实践中需注意适度细化,避免过度设计。
36 6
|
2月前
|
供应链 Java BI
SOLID设计原则系列之--单一职责原则
本文详细探讨了单一职责原则(SRP),通过分析其定义演变,解释了如何确保软件模块职责单一。文中提供了两个Java示例,展示了违反SRP的设计问题及其解决方案。总结了SRP在实际工作中的应用,并强调了其对提高代码质量和系统灵活性的重要性。适合开发者学习参考。
28 6
|
2月前
|
存储 Java 数据库连接
SOLID设计原则:依赖倒置原则
本文介绍了依赖倒置原则,即高层模块不依赖低层模块,而是共同依赖抽象。直接依赖会导致紧耦合、难以测试和重用性差等问题。通过引入抽象层或独立抽象组件包,可以实现依赖倒置,提高系统灵活性和可维护性。Spring 和 Java SPI 是依赖倒置原则的典型应用。遵循该原则有助于设计更灵活、可扩展的系统架构。
47 3
|
3月前
|
关系型数据库 开发者
|
4月前
|
关系型数据库 测试技术
|
设计模式 安全 Java
设计原则之依赖倒置原则
设计原则之依赖倒置原则
79 0
设计原则之依赖倒置原则
|
消息中间件 设计模式 存储
【Java设计模式 经典设计原则】二 SOLID-OCP开闭原则
【Java设计模式 经典设计原则】二 SOLID-OCP开闭原则
99 0
|
设计模式 XML JSON
【Java设计模式 经典设计原则】一 SOLID-SRP单一职责原则
【Java设计模式 经典设计原则】一 SOLID-SRP单一职责原则
98 0
|
设计模式 消息中间件 存储
【Java设计模式 经典设计原则】四 SOLID-ISP接口隔离原则
【Java设计模式 经典设计原则】四 SOLID-ISP接口隔离原则
171 0