设计原则之【开闭原则】

文章目录

什么是开闭原则
简单实例
实战实例
如何理解“对修改关闭”？修改代码就一定违背开闭原则吗
参考资料

什么是开闭原则

开闭原则的英文全称是 Open Closed Principle，简写为 OCP。它的英文描述是：software entities (modules, classes, functions, etc.) should be open for extension , but closed for modification。我们把它翻译成中文就是：软件实体（模块、类、方法等）应该“对扩展开放、对修改关闭”。

可扩展性，就是，添加一个新的功能应该是，在已有代码基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等）。是衡量代码质量最重要的标准之一。

开闭原则理解起来并不难，难的是能够灵活的应用到实际开发工作中。

简单实例

以下代码相信也不陌生，这就是典型的使用面向对象语言做着面向过程的事：

package com.study;

public class Ocp {

    public static void main(String[] args) {
        GraphicEditor graphicEditor = new GraphicEditor();
        graphicEditor.drawShape(new Rectangle());
        graphicEditor.drawShape(new Circle());
        graphicEditor.drawShape(new Triangle());
    }
}

//这是一个用于绘图的类 [使用方]
class GraphicEditor {
    //接收 Shape 对象，然后根据 type，来绘制不同的图形
    public void drawShape(Shape s) {
        if (s.m_type == 1){
            drawRectangle(s);
        } else if (s.m_type == 2){
            drawCircle(s);
        } else if (s.m_type == 3){
            drawTriangle(s);
        }
    }

    //绘制矩形
    public void drawRectangle(Shape r) {
        System.out.println(" 绘制矩形 ");
    }

    //绘制圆形
    public void drawCircle(Shape r) {
        System.out.println(" 绘制圆形 ");
    }

    //绘制三角形
    public void drawTriangle(Shape r) {
        System.out.println(" 绘制三角形 ");
    }
}

//Shape 类，基类
class Shape {
    int m_type;
}

class Rectangle extends Shape {
    Rectangle() {
        super.m_type = 1;
    }
}

class Circle extends Shape {
    Circle() {
        super.m_type = 2;
    }
}

//新增画三角形
class Triangle extends Shape {
    Triangle() {
        super.m_type = 2;
    }
}

优化后：

package com.study;

public class Ocp {

    public static void main(String[] args) {
        GraphicEditor graphicEditor = new GraphicEditor();
        graphicEditor.drawShape(new Rectangle());
        graphicEditor.drawShape(new Circle());
        graphicEditor.drawShape(new Triangle());
    }
}

//这是一个用于绘图的类 [使用方]
class GraphicEditor {
    //接收 Shape 对象，然后根据 type，来绘制不同的图形
    public void drawShape(Shape s) {
        s.draw();
    }
}

//Shape 类，基类
abstract class Shape {
    abstract void draw();
}

class Rectangle extends Shape {
    @Override
    void draw() {
        System.out.println(" 绘制矩形 ");
    }
}

class Circle extends Shape {
    @Override
    void draw() {
        System.out.println(" 绘制圆形 ");
    }
}

//新增画三角形
class Triangle extends Shape {
    @Override
    void draw() {
        System.out.println(" 绘制三角形 ");
    }
}

实战实例

现在有一个登录逻辑：

public class Login {
  private AccountService accountService;

  @Autoware
  public Login (AccountService accountService) {
    this.accountService = accountService;
  }

  public boolean loginCheck(String password, String name) {
    // 检查账号密码
    if(!accountService.checkPwd(password, name)){
    return false;
  }
  // 检查登录失败次数
  if(accountService.getLoginErrorCount() >= 5){
    return false;
    }
    return true;
  }
}

上述代码相信很多小伙伴都会遇到，看上去似乎并没有什么大问题。

但是，现在新增一个逻辑：登录时，我要校验验证码是否正确，代码可能需要做以下改动：

public class Login {
  private AccountService accountService;

  @Autoware
  public Login (AccountService accountService) {
    this.accountService = accountService;
  }

  // 改动1：方法添加参数
  public boolean loginCheck(String password, String name, String verificationCode) {
    // 检查账号密码
    if(!accountService.checkPwd(password, name)){
    return false;
  }
  // 检查登录失败次数
  if(accountService.getLoginErrorCount() >= 5){
    return false;
    }
    // 改动2：检查验证码
    if(!accountService.getVerificationCode().equals(verificationCode)){
    return false;
    }
    return true;
  }
}

这样的代码修改实际上存在挺多问题的。一方面，我们对接口进行了修改，这就意味着调用这个接口的代码都要做相应的修改。另一方面，修改了 loginCheck() 函数内容，相应的单元测试及其他逻辑都需要修改。

接下来我们重构一下Login的代码，让其具备扩展性，重构包括两部分：

第一部分是将 loginCheck() 函数的多个入参封装成 LoginCheckInfo类；
第二部分是引入 handler 的概念，将 if 判断逻辑分散在各个 handler 中。

public class LoginCheckInfo {//省略constructor/getter/setter方法
  private String name;
  private String password;
  private String verificationCode;
}

public class Login {
  private List<LoginCheckHandler> checkHandlers = new ArrayList<>();
  
  public void addLoginCheckHandler(CheckHandler checkHandler) {
    this.checkHandlers.add(checkHandler);
  }

  public void check(LoginCheckInfo loginCheckInfo) {
    for (LoginCheckHandlerhandler : checkHandlers) {
      boolean result = handler.check(loginCheckInfo);
      // 处理逻辑
    }
  }
}

public abstract class CheckHandler {
  private AccountService accountService;

  @Autoware
  public CheckHandler (AccountService accountService) {
    this.accountService = accountService;
  }
  public abstract void check(LoginCheckInfo loginCheckInfo);
}

public class PwdCheckHandler extends CheckHandler {
  public PwdCheckHandler(AccountService accountService) {
    super(accountService);
  }

  @Override
  public boolean check(LoginCheckInfo loginCheckInfo) {
    return accountService.checkPwd(loginCheckInfo.getPassword(), loginCheckInfo.getName());
  }
}

public class LoginCountCheckHandler extends CheckHandler {
  public LoginCountCheckHandler(AccountService accountService) {
    super(accountService);
  }

  @Override
  public boolean check(LoginCheckInfo loginCheckInfo) {
    return accountService.getLoginErrorCount() >= 5;
  }
}

要想使用我们重构后的登录逻辑：

@Bean
public Login login(){
  Login login = new Login();
  login.addLoginCheckHandler(new PwdCheckHandler());
  login.addLoginCheckHandler(new LoginCountCheckHandler());
}

// 只需要在service层注入login，然后调用login.check();即可

此时，我们如果想要扩展验证码功能：

public class VerificationCodeCheckHandler extends CheckHandler {
  public VerificationCodeCheckHandler(AccountService accountService) {
    super(accountService);
  }

  @Override
  public boolean check(LoginCheckInfo loginCheckInfo) {
    return accountService.getVerificationCode().equals(loginCheckInfo.getVerificationCode());
  }
}

// 然后在定义Login的bean中将这个处理器添加进去即可。
login.addLoginCheckHandler(new VerificationCodeCheckHandler());

重构之后的代码更加灵活和易扩展。如果我们要想添加新的告警逻辑，只需要基于扩展的方式创建新的 handler 类即可，不需要改动原来的 check() 函数的逻辑。而且，我们只需要为新的 handler 类添加单元测试，老的单元测试都不会失败，也不用修改。

如何理解“对修改关闭”？修改代码就一定违背开闭原则吗

对修改关闭的前提是：对扩展开放。

，添加一个新功能，不可能任何模块、类、方法的代码都不“修改”，这个是做不到的。类需要创建、组装、并且做一些初始化操作，才能构建成可运行的的程序，这部分代码的修改是在所难免的。我们要做的是尽量让修改操作更集中、更少、更上层，尽量让最核心、最复杂的那部分逻辑代码满足开闭原则。

也就是说，对拓展开放是为了应对变化(需求)，对修改关闭是为了保证已有代码的稳定性；最终结果是为了让系统更有弹性！

添加一个新的功能，如果能够保证老的核心代码不会被修改，那么这就是符合开闭原则的。

熟练使用各种设计模式、并且应用到实际工作中，是我们开发者一生都要去学习的。

但是，熟悉了“开闭原则”，这并不意味着你需要随时随地都要考虑扩展。需求永远是在不断变化的，即便我们对业务、对系统有足够的了解，那也不可能识别出所有的扩展点，即便你能识别出所有的扩展点，为这些地方都预留扩展点，这样做的成本也是不可接受的。我们没必要为一些遥远的、不一定发生的需求去提前买单，做过度设计。

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

设计原则之【开闭原则】

文章目录

什么是开闭原则

简单实例

实战实例

如何理解“对修改关闭”？修改代码就一定违背开闭原则吗

继续阅读

HDU 4719 Oh My Holy FFF

CSU 1561 (More) Multiplication

CSU 1563 Lexicography

HDU 4721 Food and Productivity

ZOJ 1041 Transmitters

CSU 1562 Fun House

CodeChef PALPROB Palindromeness

UVA 10344- 23 out of 5

ZOJ 1104 Leaps Tall Buildings

HDU 2821 Pusher

UVA 1401 Remember the Word

ZOJ 2748 Free Kick

CSU 1567 Reverse Rot

JAVA 系列——>开发工具IntelliJ IDEA的安装以及配置、快捷键IDEA 简介

UVA 519 Puzzle (II)

磁盘结构及在Linux中的命名