面向对象的六大原则（二）

发表于 | 分类于

开闭原则的定义

开闭原则的英文名称是Open-Close Principle，简称是OCP。开闭原则的定义是:Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification.软件实体（类，模块，方法等等）应当对扩展开放，对修改关闭，即软件实体应当在不修改的前提下扩展。

开闭原则的真面目

问题由来:在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。

开闭原则的定义已经非常明确地告诉我们：软件实体应该对扩展开放，对修改关闭，其含义是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。那什么又是软件实体呢？软件实体包括以下几个部分：

  • 项目或软件产品中按照一定的逻辑规则划分的模块
  • 抽象和类
  • 方法

一个软件产品只要在生命期内，都会发生变化，既然变化是一个既定的事实，我们就应该在设计时尽量适应这些变化，以提高项目的稳定性和灵活性，真正实现“拥抱变化”。开闭原则告诉我们应尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来完成变化，它是为软件实体的未来事件而制定的对现行开发设计进行约束的一个原则。

开闭原则的示例

以书店销售书籍为例，类图如下所示
ShowImage

IBook定义了书的三个属性：名称，价格和作者。小说类NovelBook是一个具体的实现类，是所有小说书籍的总称，BookStore是书店，和书有关联关系。IBook代码如下所示：

1
2
3
4
5
6
7
8
9
10
public interface IBook {
    //获取书籍名称
    String getName();
    //获取书籍价格
    int getPrice();
    //获取书籍作者
    String getAuthor();
}

假设目前书店只出售小说类书籍，小说类代码如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
public class NovelBook implements IBook {
    //书籍名称
    private String name;
    //书籍价格
    private int price;
    //书籍作者
    private String author;
    //通过构造函数传递书籍数据
    public NovelBook(String name, int price, String author) {
        this.name = name;
        this.price = price;
        this.author = author;
    }
    //获取作者名字
    @Override
    public String getAuthor() {
        return author;
    }
    //获取书籍名字
    @Override
    public String getName() {
        return name;
    }
    //获取书籍价格
    @Override
    public int getPrice() {
        return price;
    }
}

书店售书的过程代码如下所示

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class BookStore {
    private final static ArrayList<IBook> bookList = new ArrayList<IBook>();
    //手动添加数据
    static {
        bookList.add(new NovelBook("天龙八部", 4500, "金庸"));
        bookList.add(new NovelBook("射雕英雄传", 4000, "金庸"));
        bookList.add(new NovelBook("The Lord of the Rings", 6000, "Tolkien"));
        bookList.add(new NovelBook("The Hobbit", 5000, "Tolkien"));
    }
    public static void main(String[] args) {
        NumberFormat formatter = NumberFormat.getCurrencyInstance();
        formatter.setMaximumFractionDigits(2);
        System.out.println("-----------书店卖出去的书籍记录如下-----------");
        for (IBook book : bookList) {
            System.out.println("书籍名称: " + book.getName() + "\t书籍作者: " + book.getAuthor() + "\t书籍价格: " + formatter.format(book.getPrice() /
                    100.0) + "元");
        }
    }

运行结果如下

1
2
3
4
5
-----------书店卖出去的书籍记录如下-----------
书籍名称: 天龙八部	书籍作者: 金庸	书籍价格: ￥45.00元
书籍名称: 射雕英雄传	书籍作者: 金庸	书籍价格: ￥40.00元
书籍名称: The Lord of the Rings	书籍作者: Tolkien	书籍价格: ￥60.00元
书籍名称: The Hobbit	书籍作者: Tolkien	书籍价格: ￥50.00元

小说书很畅销，书店也运营得很成功，马上就要过五一劳动节了，老板决定回馈老客户，50元以上的书本打9折销售，其余书本打8折销售。这时候我们要思考下程序设计的变化了。有三种办法可以解决我们新的需求：

  • 修改接口

在IBook上新增加一个方法getOffPrice()，专门用于进行打折处理，所有的实现类实现该方法。但是这样修改的后果就是，实现类NovelBook要修改，BookStore中的main方法也修改，同时IBook作为接口应该是稳定且可靠的，不应该经常发生变化，否则接口作为契约的作用就失去了效能。因此，该方案否定。

  • 修改实现类

修改NovelBook类中的方法，直接在getPrice()中实现打折处理，好办法，我相信大家在项目中经常使用的就是这样的办法，通过class文件替换的方式可以完成部分业务变化（或是缺陷修复）。该方法在项目有明确的章程（团队内约束）或优良的架构设计时，是一个非常优秀的方法，但是该方法还是有缺陷的。例如采购书籍人员也是要看价格的，由于该方法已经实现了打折处理价格，因此采购人员看到的也是打折后的价格，会因信息不对称而出现决策失误的情况。因此，该方案也不是一个最优的方案。

  • 通过扩展实现变化

增加一个子类OffNovelBook，覆写getPrice方法，高层次的模块（也就是static静态模块区）通过OffNovelBook类产生新的对象，完成业务变化对系统的最小化开发。好办法，修改也少，风险也小，修改后的类图如下所示。

ShowImage

OffNovelBook类继承了NovelBook，并覆写了getPrice方法，不修改原有的代码。新增的offNovelBook代码如下所示

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public class OffNovelBook extends NovelBook {
    public OffNovelBook(String name, int price, String author) {
        super(name, price, author);
    }
    @Override
    public int getPrice() {
        //获取原价
        int selfPrice = super.getPrice();
        int offPrice = 0;
        //大于40元的打9折，否则打8折
        if (selfPrice > 4000) {
            offPrice = selfPrice * 90 / 100;
        } else {
            offPrice = selfPrice * 80 / 100;
        }
        return offPrice;
    }
}

仅仅覆写了getPrice()方法，通过扩展完成了新增加的业务。BookStore类也稍作修改

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
public class BookStore {
    private final static ArrayList<IBook> bookList = new ArrayList<IBook>();
    //手动添加数据
    static {
        bookList.add(new OffNovelBook("天龙八部", 4500, "金庸"));
        bookList.add(new OffNovelBook("射雕英雄传", 4000, "金庸"));
        bookList.add(new OffNovelBook("The Lord of the Rings", 6000, "Tolkien"));
        bookList.add(new OffNovelBook("The Hobbit", 5000, "Tolkien"));
    }
    public static void main(String[] args) {
        NumberFormat formatter = NumberFormat.getCurrencyInstance();
        formatter.setMaximumFractionDigits(2);
        System.out.println("-----------书店卖出去的书籍记录如下-----------");
        for (IBook book : bookList) {
            System.out.println("书籍名称: " + book.getName() + "\t书籍作者: " + book.getAuthor() + "\t书籍价格: " + formatter.format(book.getPrice() /
                    100.0) + "元");
        }
    }
}

运行结果如下

1
2
3
4
5
-----------书店卖出去的书籍记录如下-----------
书籍名称: 天龙八部	书籍作者: 金庸	书籍价格: ￥40.50元
书籍名称: 射雕英雄传	书籍作者: 金庸	书籍价格: ￥32.00元
书籍名称: The Lord of the Rings	书籍作者: Tolkien	书籍价格: ￥54.00元
书籍名称: The Hobbit	书籍作者: Tolkien	书籍价格: ￥45.00元

增加offNovelBook类后，只在持久层做了少量修改就完成了需求，降低了代码大量修改所带来的风险。

开闭原则的归纳

我们可以把变化归纳成以下三种类型

  • 逻辑变化

只变化一个逻辑，而不涉及其他模块，比如原有的一个算法是ab+c，现在需要修改为ab*c，可以通过修改原有类中的方法的方式来完成，前提条件是所有依赖或关联类都按照相同的逻辑处理。

  • 子模块变化

一个模块变化，会对其他的模块产生影响，特别是一个低层次的模块变化必然引起高层模块的变化，因此在通过扩展完成变化时，高层次的模块修改是必然的，刚刚的书籍打折处理就是类似的处理模块，该部分的变化甚至会引起界面的变化。

  • 可见视图变化

可见视图是提供给客户使用的界面，如JSP程序、Swing界面等，该部分的变化一般会引起连锁反应（特别是在国内做项目，做欧美的外包项目一般不会影响太大）。如果仅仅是界面上按钮、文字的重新排布倒是简单，最司空见惯的是业务耦合变化，什么意思呢？一个展示数据的列表，按照原有的需求是6列，突然有一天要增加1列，而且这一列要跨N张表，处理M个逻辑才能展现出来，这样的变化是比较恐怖的，但还是可以通过扩展来完成变化，这就要看我们原有的设计是否灵活。

为什么要使用开闭原则

开闭原则对测试的影响

所有已经投产的代码都是有意义的，并且都受系统规则的约束，这样的代码都要经过“千锤百炼”的测试过程，不仅保证逻辑是正确的，还要保证苛刻条件（高压力、异常、错误）下不产生“有毒代码”（Poisonous Code），因此有变化提出时，我们就需要考虑一下，原有的健壮代码是否可以不修改，仅仅通过扩展实现变化呢？否则，就需要把原有的测试过程回笼一遍，需要进行单元测试、功能测试、集成测试甚至是验收测试，现在虽然在大力提倡自动化测试工具，但是仍然代替不了人工的测试工作。
以上面提到的书店售书为例，IBook接口写完了，实现类NovelBook也写好了，我们需要写一个测试类进行测试，测试类如下所示。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class NovelBookTest {
    private String name = "神雕侠侣";
    private int price = 5200;
    private String author = "金庸";
    private IBook novelBook = new NovelBook(name, price, author);
    //测试getPrice()方法
    @Test
    public void testGetPrice() {
        assertEquals("神雕侠侣", novelBook.getName());
        assertEquals(5200, novelBook.getPrice());
        assertEquals("金庸", novelBook.getAuthor());
    }
}

原有的NovelBook的getPrice()方法的单元测试绿灯通过。

在书店售书的例子中，增加了一个打折销售的需求，如果我们直接修改getPrice方法来实现业务需求的变化，那就要修改单元测试类。想想看，我们举的这个例子是非常简单的，如果是一个复杂的逻辑，你的测试类就要修改得面目全非。还有，在实际的项目中，一个类一般只有一个测试类，其中可以有很多的测试方法，在一堆本来就很复杂的断言中进行大量修改，难免会出现测试遗漏情况，这是项目经理很难容忍的事情。

所以，我们需要通过扩展来实现业务逻辑的变化，而不是修改。上面的例子中通过增加一个子类OffNovelBook来完成了业务需求的变化，这对测试有什么好处呢？我们重新生成一个测试文件OffNovelBookTest，然后对getPrice进行测试，单元测试是孤立测试，只要保证我提供的方法正确就成了，其他的我不管，OffNovelBookTest代码如下所示。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public class OffNovelBookTest {
    private IBook below40NovelBook = new OffNovelBook("人民的名义", 3500, "周梅森");
    private IBook above40NovelBook = new OffNovelBook("百年孤独", 5000, "加西亚马尔克斯");
    //测试低于40元的书打8折
    @Test
    public void testGetPriceBelow40() {
        assertEquals("人民的名义", below40NovelBook.getName());
        assertEquals(2800, below40NovelBook.getPrice());
        assertEquals("周梅森", below40NovelBook.getAuthor());
    }
    //测试大于40元的书打9折
    @Test
    public void testGetPriceAbove40() {
        assertEquals("百年孤独", above40NovelBook.getName());
        assertEquals(4500, above40NovelBook.getPrice());
        assertEquals("加西亚马尔克斯", above40NovelBook.getAuthor());
    }
}

测试完两个小绿灯通过。新增加的类，新增加的测试方法，只要保证新增加类是正确的就可以了。

开闭原则可以提高复用性

在面向对象的设计中，所有的逻辑都是从原子逻辑组合而来的，而不是在一个类中独立实现一个业务逻辑。只有这样代码才可以复用，粒度越小，被复用的可能性就越大。那为什么要复用呢？减少代码量，避免相同的逻辑分散在多个角落，避免日后的维护人员为了修改一个微小的缺陷或增加新功能而要在整个项目中到处查找相关的代码，然后发出对开发人员“极度失望”的感慨。那怎么才能提高复用率呢？缩小逻辑粒度，直到一个逻辑不可再拆分为止。

开闭原则可以提高可维护性

一款软件投产后，维护人员的工作不仅仅是对数据进行维护，还可能要对程序进行扩展，维护人员最乐意做的事情就是扩展一个类，而不是修改一个类，甭管原有的代码写得多么优秀还是多么糟糕，让维护人员读懂原有的代码，然后再修改，是一件很痛苦的事情，不要让他在原有的代码海洋里游弋完毕后再修改，那是对维护人员的一种折磨和摧残。

面向对象开发的要求

万物皆对象，我们需要把所有的事物都抽象成对象，然后针对对象进行操作，但是万物皆运动，有运动就有变化，有变化就要有策略去应对，怎么快速应对呢？这就需要在设计之初考虑到所有可能变化的因素，然后留下接口，等待“可能”转变为“现实”。

开闭原则的使用实践

抽象约束

抽象是对一组事物的通用描述，没有具体的实现，也就表示它可以有非常多的可能性，可以跟随需求的变化而变化。因此，通过接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放，其包含三层含义：第一，通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；第二，参数类型、引用对象尽量使用接口或者抽象类，而不是实现类；第三，抽象层尽量保持稳定，一旦确定即不允许修改。

还是以书店为例，目前只是销售小说类书籍，单一经营毕竟是有风险的，于是书店新增加了计算机书籍，它不仅包含书籍名称、作者、价格等信息，还有一个独特的属性：面向的是什么领域，也就是它的范围，比如是和编程语言相关的，还是和数据库相关的，等等，修改后的类图如下所示。

ShowImage

增加了一个接口IComputerBook和实现类ComputerBook，而BookStore不用做任何修改就可以完成书店销售计算机书籍的业务。

所以，要实现对扩展开放，首要的前提条件就是抽象约束。

元数据（metadata）控制模块行为

编程是一个很苦很累的活，那怎么才能减轻我们的压力呢？答案是尽量使用元数据来控制程序的行为，减少重复开发。什么是元数据？用来描述环境和数据的数据，通俗地说就是配置参数，参数可以从文件中获得，也可以从数据库中获得。举个非常简单的例子，login方法中提供了这样的逻辑：先检查IP地址是否在允许访问的列表中，然后再决定是否需要到数据库中验证密码（如果采用SSH架构，则可以通过Struts的拦截器来实现），该行为就是一个典型的元数据控制模块行为的例子。

制定项目章程

在一个团队中，建立项目章程是非常重要的，因为章程中指定了所有人员都必须遵守的约定，对项目来说，约定优于配置。相信大家都做过项目，会发现一个项目会产生非常多的配置文件。举个简单的例子，以SSH项目开发为例，一个项目中的Bean配置文件就非常多，管理非常麻烦。如果需要扩展，就需要增加子类，并修改SpringContext文件。然而，如果你在项目中指定这样一个章程：所有的Bean都自动注入，使用Annotation进行装配，进行扩展时，甚至只用写一个子类，然后由持久层生成对象，其他的都不需要修改，这就需要项目内约束，每个项目成员都必须遵守，该方法需要一个团队有较高的自觉性，需要一个较长时间的磨合，一旦项目成员都熟悉这样的规则，比通过接口或抽象类进行约束效率更高，而且扩
展性一点也没有减少。

封装变化

对变化的封装包含两层含义：第一，将相同的变化封装到一个接口或抽象类中；第二，将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中。封装变化，也就是受保护的变化（protected variations），找出预计有变化或不稳定的点，我们为这些变化点创建稳定的接口，准确地讲是封装可能发生的变化，一旦预测到或“第六感”发觉有变化，就可以进行封装，23个设计模式都是从各个不同的角度对变化进行封装的。

参考代码

------ 本文结束 ------

版权声明


BillyYccc's blog by Billy Yuan is licensed under a Creative Commons BY-NC-SA 4.0 International License.
本文原创于BillyYccc's Blog，转载请注明原作者及出处！