开放封闭原则：不改代码怎么写新功能？

再小的努力，乘以365都很明显

前言

上一篇文章，我们讲了一个最基础的设计原则：单一职责原则。这一讲，我们来看下一个设计原则：开放封闭原则。

作为一名程序员，来了一个需求就要改一次代码，这种方式我们已经见怪不怪了，甚至已经变成了一种下意识的反应。修改也很容易，只要我们按照之前的惯例如法炮制就好了。

这是一种不费脑子的做法，却伴随着长期的伤害。每人每次都只改了一点点，但是，经过长期积累，再来一个新的需求，改动量就要很大了。而在这个过程中，每个人都很无辜，因为每个人都只是遵照惯例在修改。但结果是，所有人都受到了伤害，代码越来越难以维护。

既然“修改”会带来这么多问题，那我们可以不修改吗？开放封闭原则就提供了这样的一个新方向。

简介

开放封闭原则是这样表述的：

软件实体（类、模块、函数）应该对扩展开放，对修改封闭。

这个说法是 Bertrand Meyer 在其著作《面向对象软件构造》（Object-Oriented Software Construction）中提出来的，它给软件设计提出了一个极高的要求：不修改代码。

或许你想问，不修改代码，那我怎么实现新的需求呢？答案就是靠扩展。用更通俗的话来解释，就是新需求应该用新代码实现。

开放封闭原则向我们描述的是一个结果，就是我们可以不修改代码而仅凭扩展就完成新功能。但是，这个结果的前提是要在软件内部留好扩展点，而这正是需要我们去设计的地方。因为每一个扩展点都是一个需要设计的模型。

解释

举个例子，假如我们正在开发一个酒店预订系统，针对不同的用户，我们需要计算出不同的房价。比如，普通用户是全价，金卡是 8 折，银卡是 9 折，代码写出来可能是这样的：

class HotelService {
  public double getRoomPrice(final User user, final Room room) {
    double price = room.getPrice();
    if (user.getLevel() == Level.GOLD) {
      return price * 0.8;
    }
    
    if (user.getLevel() == Level.SILVER) {
      return price * 0.9;
    }
    
    return price;
  }
}

这时，新的需求来了，要增加白金卡会员，给出 75 折的优惠，如法炮制的写法应该是这样的：

class HotelService {
  public double getRoomPrice(final User user, final Room room) {
    double price = room.getPrice();
    if (user.getLevel() == UserLevel.GOLD) {
      return price * 0.8;
    }
    
    if (user.getLevel() == UserLevel.SILVER) {
      return price * 0.9;
    }
    
    if (user.getLevel() == UserLevel.PLATINUM) {
      return price * 0.75;
    }
    
    return price;
  }
}

显然，这种做法就是修改代码的做法，每增加一个新的类型就要修改一次代码。但是，一个有各种级别用户的酒店系统肯定不只是房价有区别，提供的服务也可能有区别。可想而知，每增加一个用户级别，我们要改的代码就漫山遍野。

那应该怎么办呢？我们应该考虑如何把它设计成一个可以扩展的模型。在这个例子里面，既然每次要增加的是用户级别，而且各种服务的差异都体现在用户级别上，我们就需要一个用户级别的模型。在前面的代码里，用户级别只是一个简单的枚举，我们可以给它丰富一下：

interface UserLevel {
  double getRoomPrice(Room room);
}

class GoldUserLevel implements UserLevel {
  public double getRoomPrice(final Room room) {
    return room.getPrice() * 0.8;
  }
}

class SilverUserLevel implements UserLevel {
  public double getRoomPrice(final Room room) {
    return room.getPrice() * 0.9;
  }
}

我们原来的代码就可以变成这样：

class HotelService {
  public double getRoomPrice(final User user, final Room room) {
    return user.getRoomPrice(room);
  }
}

class User {
  private UserLevel level;
  ...
  
  public double getRoomPrice(final Room room) {
    return level.getRoomPrice(room);
  }
}

这样一来，再增加白金用户，我们只要写一个新的类就好了：

class PlatinumUserLevel implements UserLevel {
  public double getRoomPrice(final Room room) {
    return room.getPrice() * 0.75;
  }
}

之所以我们可以这么做，是因为我们在代码里留好了扩展点：UserLevel。在这里，我们把原来的只支持枚举值的 UserLevel 升级成了一个有行为的 UserLevel。

经过这番改造，HotelService 的 getRoomPrice 这个方法就稳定了下来，我们就不需要根据用户级别不断地调整这个方法了。至此，我们就拥有了一个稳定的构造块，可以在后期的工作中把它当做一个稳定的模块来使用。

当然，在这个例子里，这个方法是比较简单的。而在实际的项目中，业务方法都会比较复杂。

总结

今天，我们讲了开放封闭原则，软件实体应该对扩展开放，对修改封闭。简单地说，就是不要修改代码，新的功能要用新的代码实现。

其实，道理大家都懂，但对很多人来说，做到是有难度的，尤其是在代码里留下扩展点，往往是需要有一定设计能力的。很多优秀的软件在设计上都给我们提供了足够的扩展能力，向这些软件的接口学习，我们可以学到更多的东西。

显然，要想提供扩展点，就需要面向接口编程。但是，是不是有了接口，就是好的设计了呢？下一讲，我们来看设计一个接口还需要满足什么样的原则。