设计原则:开闭原则(OCP)

1.什么是开闭原则

开闭原则的英文是Open Closed Principle,缩写就是OCP。其定义如下:

软件实体(模块、类、方法等)应该“对扩展开放、对修改关闭”。

从定义上看,这个原则主要包含两部分:

  • 对扩展开放:“ 这意味着模块的行为是可以扩展的。当应用程序的需求改变时,我们可以对其模块进行扩展,使其具有满足那些需求变更的新行为。换句话说,我们可以改变模块的功能。

  • 对修改关闭:“ 对模块行为进行扩展时,不必改动该模块的源代码或二进制代码。模块的二进制可执行版本,无论是可链接的库、DLL或Java的.jar文件,都无需改动。

通俗解释就是,添加一个新的功能,应该通过在已有代码(模块、类、方法)的基础上进行扩展来实现,而不是修改已有代码。

之前的一篇文章《何谓高质量代码?》中,我们总结了高质量代码的几个衡量标准。

而开闭原则解决的就是代码的扩展性问题。如果某段代码在应对未来需求变化的时候,能够做到“对扩展开放、对修改关闭”,那就说明这段代码的扩展性比较好。

2.如何做到对扩展开放、对修改关闭

那么应该怎样写出扩展性好的代码呢?

在思想上我们要具备扩展意识、抽象意识、封装意识。这些意识的培养要比一些具体的方法更为重要,这依赖我们对面向对象的理解、对业务的掌握度,以及长期的经验积累...... 这要求我们在写代码的时候后,要多花点时间往前多思考一下,未来可能有哪些需求变更,识别出代码的易变部分与不易变部分,合理设计代码结构,事先留好扩展点,以便在未来不需要改动代码整体结构、做到最小代码改动的情况下,新的代码能够很灵活地插入到扩展点上。

在方法上,我们主要可以通过多态、依赖注入、面向接口编程等方式来实现代码的可扩展性。做到“对扩展开放、对修改关闭”。我们要将可变部分抽象出来以隔离变化,提供抽象化的不可变接口,给上层系统使用。当具体的实现发生变化的时候,我们只需要基于相同的抽象接口,扩展一个新的实现,替换掉老的实现即可,上游系统的代码几乎不需要修改。

比如,我们的项目中通常会用到一些第三方组件,消息中间件,缓存中间件......消息中间件我们可能一开始使用RabbitMQ,但是可能后来会换成Kafka,缓存中间件可能会从Memcache换成Redis。这种情况,如果我们的上层应用直接依赖这些中间件调用代码,那么更换的成本就会更高,这种代码就不利于扩展。

image-20210203082100894

public class MemcacheClient {

    public boolean set(String key, String value) {
        return false;
    }

    public String get(String key) {
        return null;
    }

    public boolean remove(String key) {
        return false;
    }
}

public class OcpApplication {

    public void test() {

        // 业务代码
        //...
        //...

        //写缓存
        MemcacheClient client = new MemcacheClient();
        client.set("testKey", "testValue");
    }
}

如上示例,我们的上层应用OcpApplication直接依赖了MemcacheClient,如果未来有需要把Memcache换成Redis,我们就需要替换掉所有调用了MemcacheClient的上层应用方法,这严重违背了开闭原则。

在这种情况下,通常我们会把这种中间件的调用设计成可插拔的。我们提供一个这些中间件的抽象接口出来,让所有上层系统都依赖这组抽象的接口编程,并且通过依赖注入的方式来调用。当我们要替换新的中间件的时候,比如将 Memcache替换成 Redis,就可以可以很方便地拔掉老的Memecache实现,插入新的Redis实现。

image-20210203080434828

/**
 * 缓存中间件的使用抽象出接口
 */
public interface ICacheClient {

    boolean set(String key, String value);

    String get(String key);

    boolean remove(String key);
}

/**
 * MemcacheClient
 */
public class MemcacheClient implements ICacheClient {

    public boolean set(String key, String value) {
        return false;
    }

    public String get(String key) {
        return null;
    }

    public boolean remove(String key) {
        return false;
    }
}

/**
 * RedisClient
 */
public class RedisClient implements ICacheClient {
    
    @Override
    public boolean set(String key, String value) {
        return false;
    }

    @Override
    public String get(String key) {
        return null;
    }

    @Override
    public boolean remove(String key) {
        return false;
    }
}

public class OcpApplication {

    /**
     * 依赖注入cacheClient
     */
    ICacheClient cacheClient;
    
    public OcpApplication(ICacheClient cacheClient){
        this.cacheClient=cacheClient;
    }

    public void test() {

        // 业务代码
        //...
        //...

        //写缓存
        cacheClient.set("testKey", "testValue");
    }
}

3.如何灵活运用开闭原则

开闭原则看似简单,但我却认为是SOLID 中最难掌握的一条原则。其难点就在于如何在真正的项目中去灵活运动开闭原则。而且OCP同样存在着一些陷阱,怎么才算满足或违反开闭原则,修改代码就一定意味着违反开闭原则吗,扩展点设计的越多越好吗......

3.1 灵活设计扩展点

对于业务系统,要想识别出尽可能多的扩展点,就要求你对业务有足够的了解,能够预见一些未来可能的变化。

对于偏技术的系统,比如,框架、组件、类库等,就需要充分了解它的使用场景?以及今后想要扩展点功能?使用者未来会有哪些更多的诉求......

但即便我们对业务、对系统有足够的了解,也不可能识别出所有的扩展点,即便可以,并为这些地方都预留扩展点,也是没有必要的。同样有一条原则叫KISS原则,那就是尽量保持简单,不要进行过度设计,实际上很多人都会陷入这样一个误区,我们常常为了一些很可能不存在的扩展而绞尽脑汁!

最合理的做法就是,对于一些比较确定的、短期内可能就会扩展,或者需求改动对代码结构影响比较大的情况,或者实现成本不高的扩展点,可以事先做些扩展性设计。但对于一些不确定未来是否要支持的需求,或者实现起来比较复杂的扩展点,我们可以等到有需求驱动的时候,再通过重构代码的方式来支持扩展的需求。

3.2 修改代码一定违反开闭原则吗

开闭原则中对于修改是封闭的并非是一个绝对的概念。

1.修复缺陷所做的改动

缺陷在软件中很常见,是不可能完全消除的。当缺陷出现时,就需要我们修复现有的代码。软件修复明显倾向于实用主义而不是坚持开放封闭原则。

2.客户端无法感知到的改动

如果一个类的改动会引起另一个类的改动,那么这两个类就是紧密耦合的。相反,如果一个类的修改总是独立的,并不会引起其他类的改动,那么这些类就是松散耦合的。我们要记住,任何情况下,松散耦合都比紧密耦合要好。如果我们对现有代码的修改不会影响客户端代码,那么也就谈不上违背开放封闭原则。

3.修改还是扩展?

从开闭原则定义中,我们可以看出,开闭原则可以应用在不同粒度的代码中,可以是模块,也可以类,还可以是方法(及其属性)。同样一个代码改动,在粗代码粒度下,可以被认定为“修改”,但在细代码粒度下,又可以被认定为“扩展”。

比如,在类这个层面添加属性和方法相当于修改类,这个代码改动可以被认定为“修改”;但这个改动并没有修改已有的属性和方法,在方法(及其属性)这一层面,它又可以被认定为“扩展”。

实际上,当纠结于某个代码改动是“修改”还是“扩展”的时候,我们就已经背离了设计原则的初衷,开闭原则的本质目的就是为了让我们的代码更具有扩展性,更容易维护,如果我们可以很容易的完成修改,又不会影响到既有的代码与单测,就可以认为这是一个合理的改动。

3.3 扩展性与可读性的平衡

在有些情况下,代码的扩展性会跟可读性相冲突。为了更好地支持扩展性,我们对代码进行了重构,重构之后的代码要比之前的代码复杂很多,理解起来也更加有难度。实际上很多时候,我们都要结合具体的场景在扩展性和可读性之间做权衡。在某些场景下,扩展性很重要,我们就可以适当地牺牲一些可读性;而在另一些场景下,可读性更加重要,那我们就适当地牺牲一些扩展性。

小结

绝大多数情况下,我们的系统都不是一锤子买卖,通常随着需求的迭代,我们需要不断地对其进行维护与扩展。而开闭原则的思想可以很好的解决扩展性的问题,因此理解并掌握开闭原则至关重要,但这需要我们充分的理解面向对象的思想,合理的利用封装、多态等方法以及长期大量的积累!

系列文章

设计原则:单一职责(SRP)

设计原则:开闭原则(OCP)

设计原则:里式替换原则(LSP)

设计原则:接口隔离原则(ISP)

设计原则:依赖倒置原则(DIP)

何谓高质量代码?

理解RESTful API

关注下方公众号,回复“代码的艺术”,可免费获取重构、设计模式、代码整洁之道等提升代码质量等相关学习资料

posted @ 2021-04-13 07:45  Mr于  阅读(377)  评论(0编辑  收藏