【设计模式】Java设计模式 - 开闭原则

简单记录 - 慕课网 Java设计模式精讲 Debug方式+内存分析 & 设计模式之禅-秦小波

都是书上的

文章目录

• 1、开闭原则的定义
• 2、什么是开闭原则
• 3、为什么要采用开闭原则？
• 4、 如何使用开闭原则
• 5、 最佳实践

开闭原则是Java世界里最基础的设计原则，它指导我们如何建立一个稳定的、灵活的系统。

什么是设计原则呢？设计模式（Design Pattern）就是一套被反复使用、多数人知晓的、经过分类编目的代码设计经验的总结。使用设计模式的目的是为了提高代码的可重用性，让代码更容易被他人理解，使系统质量更加有保证、系统更加可靠。

1、开闭原则的定义

开闭原则(OCP:Open-Closed Principle)

• 定义：一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

  （Software entities like classes,modules and functions should be open for extension but closed for modifications.）

  即软件实体应尽量在不修改原有代码的情况下进行扩展。

• 用抽象构建框架，用实现扩展细节
• 优点：提高软件系统的可复用性及可维护性

根据开闭原则，在设计一个软件系统模块（类，方法）的时候，应该可以在不修改原有的模块（修改关闭）的基础上，能扩展其功能（扩展开放）。遵循开闭原则的系统设计，可以让软件系统可复用，并且易于维护。这也是系统设计需要遵循开闭原则的原因：

1.稳定性。开闭原则要求扩展功能不修改原来的代码，这可以让 软件系统在变化中保持稳定。

2.扩展性。开闭原则要求对扩展开放，通过扩展提供新的或改变原有的功能，让软件系统具有灵活的可扩展性。

那什么是开闭原则，为什么要使用开闭原则，怎么使用开闭原则呢？

2、什么是开闭原则

什么是开闭原则，开闭原则的庐山真面目。

开闭原则的定义明确地告诉我们：软件实体应该对扩展开放，对修改关闭，

其含义是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。那什么又是软件实体呢？

软件实体包括以下几个部分：

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

一个软件产品只要在生命期内，都会发生变化，既然变化是一个既定的事实，我们就应该在设计时尽量适应这些变化，以提高项目的稳定性和灵活性，真正实现“拥抱变化”。

开闭原则告诉我们应尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来完成变化，它是为软件实体的未来事件而制定的对现行开发设计进行约束的一个原则。

注意 （开闭原则对扩展开放，对修改关闭，并不意味着不做任何修改，低层模块的变更，必然要有高层模块进行耦合，否则就是一个孤立无意义的代码片段。底层模块变更可能导致高层模块的少量修改。）

看起来好迷惑，那就举例说明什么是开闭原则，我们以书店销售书籍为例，其类图如图所示。

书店售书类图

实线箭头 关联关系

三星空心虚线 实现关系

IBook定义了数据的三个属性：名称name、价格price和作者author。小说类NovelBook是一个具体的实现类，是所有小说书籍的总称，BookStore指的是书店，IBook接口如代码所示。

书籍接口 interface IBook

IBook.java

package ZenofDesignPatterns.ocp.section1;

/**
 * @author Liu Awen 
 * 书籍接口
 */
public interface IBook {
	
	//书籍有名称
	public String getName();
	
	//书籍有售价
	public int getPrice();
	
	//书籍有作者
	public String getAuthor();
}

           

目前书店只出售小说类书籍，小说类如代码所示。

小说类NovelBook实现了接口IBook

NovelBook.java

package ZenofDesignPatterns.ocp.section1;

/**
 * 小说书籍
 */
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;
	}
	
	//获得作者是谁
	public String getAuthor() {
		return this.author;
	}

	//书籍叫什么名字
	public String getName() {
		return this.name;
	}

	//获得书籍的价格
	public int getPrice() {
		return this.price;
	}

}

           

注意:我们把价格定义为int类型并不是错误，在非金融类项目中对货币处理时，一般取2位精度，通常的设计方法是在运算过程中扩大100倍，在需要展示时再缩小100倍，减少精度带来的误差。价格可以设置为int型，不需要设置double型的。

NumberFormat formatter = 		 NumberFormat.getCurrencyInstance();
formatter.setMaximumFractionDigits(2);//Fraction分数
System,out.println(formatter.format(book.getPrice()/100.0)+"元");
           

在运算过程中扩大100倍，在需要展示时再缩小100倍，减少精度带来的误差。

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

书店售书类 BookStore.java

package ZenofDesignPatterns.ocp.section1;

import java.text.NumberFormat;
import java.util.ArrayList;

/**
 * 书店销售书籍
 */
public class BookStore {
	private final static ArrayList<IBook> bookList = new ArrayList<IBook>();
	
	//静态模块初始化，项目中一般是从持久层初始化产生
	static{
		bookList.add(new NovelBook("设计模式-可复用面向对象软件的基础",3500,"GoF"));
		bookList.add(new NovelBook("天龙八部",3200,"金庸"));//价格乘100了
		bookList.add(new NovelBook("巴黎圣母院",5600,"雨果"));
		bookList.add(new NovelBook("悲惨世界",3500,"雨果"));
		bookList.add(new NovelBook("金瓶梅",4300,"兰陵笑笑生"));
	}
	
	//模拟书店买书
	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)+"元");
		}
	}
}

           

在BookStore中声明了一个静态模块，实现了数据的初始化，这部分应该是从持久层产生的，由持久层框架进行管理，运行结果如下：

------------书店买出去的书籍记录如下：---------------------
书籍名称：设计模式-可复用面向对象软件的基础	书籍作者：GoF	书籍价格：$35.00元
书籍名称：天龙八部	书籍作者：金庸	书籍价格：$32.00元
书籍名称：巴黎圣母院	书籍作者：雨果	书籍价格：$56.00元
书籍名称：悲惨世界	书籍作者：雨果	书籍价格：$35.00元
书籍名称：金瓶梅	书籍作者：兰陵笑笑生	书籍价格：$43.00元

Process finished with exit code 0

           

修改 改变

卖实体书不行了，书店为了生存开始打折销售：所有40元以上的书籍9折销售，其他的8折销售。

对已经投产的项目来说，这就是一个变化，我们应该如何应对这样一个需求变化？有如下三种方法可以解决这个问题：

• 修改接口

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

• 修改实现类

  修改NovelBook类中的方法，直接在getPrice()中实现打折处理，这是个不错的好办法，我们在项目中经常使用的就是这样的办法，通过class文件替换的方式可以完成部分业务变化（或是缺陷修复）。

  该方法在项目有明确的章程（团队内约束）或优良的架构设计时，是一个非常优秀的方法，但是该方法还是有缺陷的。例如采购书籍人员也是要看价格的，由于该方法已经实现了打折处理价格，因此采购人员看到的也是打折后的价格，会因信息不对称而出现决策失误的情况。因此，该方案也不是一个最优的方案。

  该方法修改了代码，不是扩展。

• 通过扩展实现变化

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

  修改后的类图如图所示。

  扩展后的书店售书类图

  

  箭头实线 关联关系 一个类把另一个类的对象作为属性

  三角空心虚线 实现关系 NovelBook实现了一个接口IBook

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

OffNovelBook.java

package ZenofDesignPatterns.ocp.section2;

/**
 * 打折销售的图书
 */
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;
		if(selfPrice>4000){  //原价大于40元，则打9折，不大于40元，打八折
			offPrice = selfPrice * 90 /100;
		}else{
			offPrice = selfPrice * 80 /100;
		}
		
		return offPrice;
	}
	
}

           

仅仅覆写了getPrice方法，通过扩展完成了新增加的业务。书店类BookStore需要依赖子类，代码稍作修改，如代码所示。

书店打折销售类

package ZenofDesignPatterns.ocp.section2;

import ZenofDesignPatterns.ocp.section1.NovelBook;

import java.awt.print.Book;
import java.text.NumberFormat;
import java.util.ArrayList;

/**
 * 打折的
 * 书店销售书籍
 */
public class BookStore {
	private final static ArrayList<IBook> bookList = new ArrayList<IBook>();
	
	//静态模块初始化，项目中一般是从持久层初始化产生
	static{
		bookList.add(new OffNovelBook("设计模式-可复用面向对象软件的基础",3500,"GoF"));
		bookList.add(new OffNovelBook("天龙八部",3200,"金庸"));
		bookList.add(new OffNovelBook("巴黎圣母院",5600,"雨果"));
		bookList.add(new OffNovelBook("悲惨世界",3500,"雨果"));
		bookList.add(new OffNovelBook("金瓶梅",4300,"兰陵笑笑生"));
	}
	
	//模拟书店买书
	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)+"元");
		}
	}
}

           

我们只是简单修改了下static静态模块区，通过OffNovelBook类产生新的对象。

运行结果如下所示

------------书店买出去的书籍记录如下：---------------------
书籍名称：设计模式-可复用面向对象软件的基础	书籍作者：GoF	书籍价格：$28.00元
书籍名称：天龙八部	书籍作者：金庸	书籍价格：$25.60元
书籍名称：巴黎圣母院	书籍作者：雨果	书籍价格：$50.40元
书籍名称：悲惨世界	书籍作者：雨果	书籍价格：$28.00元
书籍名称：金瓶梅	书籍作者：兰陵笑笑生	书籍价格：$38.70元

           

打折销售开发完成了。我们增加了一个OffNoveBook类后，业务逻辑还是修改了，修改了static静态模块区域。这部分确实修改了，该部分属于高层次的模块，是由持久层产生的，在业务规则改变的情况下高层模块必须有部分改变以适应新业务，改变要尽量地少，防止变化风险的扩散。

注意 开闭原则对扩展开放，对修改关闭，并不意味着不做任何修改，低层模块的变更，必然要有高层模块进行耦合，否则就是一个孤立无意义的代码片段。

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

●逻辑变化

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

●子模块变化

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

●可见视图变化

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

我们再来回顾一下书店销售书籍的程序，首先是我们有一个还算灵活的设计（不灵活是什么样子？BookStore中所有使用到IBook的地方全部修改为实现类，然后再扩展一个ComputerBook书籍，你就知道什么是不灵活了）；然后有一个需求变化，我们通过扩展一个子类拥抱了变化；最后把子类投入运行环境中，新逻辑正式投产。通过分析，我们发现并没有修改原有的模块代码，IBook接口没有改变，NovelBook类没有改变，这属于已有的业务代码，我们保持了历史的纯洁性。放弃修改历史的想法吧，一个项目的基本路径应该是这样的：项目开发、重构、测试、投产、运维，其中的重构可以对原有的设计和代码进行修改，运维尽量减少对原有代码的修改，保持历史代码的纯洁性，提高系统的稳定性。

3、为什么要采用开闭原则？

每个事物的诞生都有它存在的必要性，存在即合理，那开闭原则的存在也是合理的，为什么这么说呢？

首先，开闭原则非常著名，只要是做面向对象编程的，甭管是什么语言，Java也好，C++也好，或者是Smalltalk，在开发时都会提及开闭原则。

其次，开闭原则是最基础的一个原则，其他的设计原则都是开闭原则的具体形态，也就是说其他的设计原则就是指导设计的工具和方法，而开闭原则才是其精神领袖。换一个角度来理解，依照Java语言的称谓，开闭原则是抽象类，其他五大原则是具体的实现类，开闭原则在面向对象设计领域中的地位就类似于牛顿第一定律在力学、勾股定律在几何学、质能方程在狭义相对论中的地位，其地位无人能及。最后，开闭原则是非常重要的，可通过以下几个方面来理解其重要性。

1.开闭原则对测试的影响

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

以上面提到的书店售书为例，IBook接口写完了，实现类NovelBook也写好了，我们需要写一个测试类进行测试，测试类如代码所示。

小说类的单元测试

NovelBookTest.java

单元测试通过，显示绿条。在单元测试中，有一句非常有名的话，叫做"Keep the bar green to keep the code clean"，即保持绿条有利于代码整洁，这是什么意思呢？绿条就是Junit运行的两种结果中的一种：要么是红条，单元测试失败；要么是绿条，单元测试通过。一个方法的测试方法一般不少于3种，为什么呢？首先是正常的业务逻辑要保证测试到，其次是边界条件要测试到，然后是异常要测试到，比较重要的方法的测试方法甚至有十多种，而且单元测试是对类的测试，类中的方法耦合是允许的，在这样的条件下，如果再想着通过修改一个方法或多个方法代码来完成变化，基本上就是痴人说梦，该类的所有测试方法都要重构，想象一下你在一堆你并不熟悉的代码中进行重构时的感觉吧！

重新测试 修改了代码 还是直接扩展吧

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

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

打折销售的小说类单元测试

新增加的类，新增加的测试方法，只要保证新增加类是正确的就可以了。

使用*extends(继承)*的方法实现原有的类的方法以及扩展其中的应用，应用去系统升级，替换实现类即可，不需要太多变动。

直接扩展 不用修改

2.开闭原则可以提高复用性

在面向对象的设计中，所有的逻辑都是从原子逻辑组合而来的，而不是在一个类中独立实现一个业务逻辑。只有这样代码才可以复用，粒度越小，被复用的可能性就越大。

那为什么要复用呢？减少代码量，避免相同的逻辑分散在多个角落，避免日后的维护人员为了修改一个微小的缺陷或增加新功能而要在整个项目中到处查找相关的代码，然后发出对开发人员“极度失望”的感慨。

那怎么才能提高复用率呢？缩小逻辑粒度，直到一个逻辑不可再拆分为止。

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

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

修改类远不如扩展一个类

4.面向对象开发的要求

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

接口编程

4、 如何使用开闭原则

开闭原则是一个非常虚的原则，其他的设计原则是对开闭原则的具体解释，但是开闭原则并不局限于这么多，它“虚”得没有边界，就像“好好学习，天天向上”的口号一样，告诉我们要好好学习，但是学什么，怎么学并没有告诉我们，需要去体会和掌握，开闭原则也是一个口号，那我们怎么把这个口号应用到实际工作中呢？

• 抽象约束。首先通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；第二，参数类型，引用对象尽量使用接口或者抽象类，而不是实现类；第三，抽象层尽量保持稳定，一旦确定既不允许修改。
• 元数据(metadata)控制模块行为。尽量使用元数据(用来描述环境和数据的数据，通俗的说就是配置参数)来控制程序的行为，减少重复开发。
• 制定项目章程。对于项目来说，约定优于配置。
• 封装变化。第一，将相同的变化封装到一个接口或抽象类中；第二，将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中。

1.抽象约束

抽象是对一组事物的通用描述，没有具体的实现，也就表示它可以有非常多的可能性，可以跟随需求的变化而变化。因此，通过接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放，其包含三层含义：

第一，通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；

第二，参数类型、引用对象尽量使用接口或者抽象类，而不是实现类；

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

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

计算机书籍接口 IComputerBook.java

package ZenofDesignPatterns.ocp.section4;

/**
 * 计算机书籍
 */
public interface IComputerBook extends IBook{
	
	//计算机书籍是有一个范围
	public String getScope();
}

           

很简单，计算机书籍增加了一个方法，就是获得该书籍的范围，同时继承IBook接口，毕竟计算机书籍也是书籍，其实现如代码所示。计算机书籍类

package ZenofDesignPatterns.ocp.section4;

/**
 * 计算机书籍
 */
public class ComputerBook implements IComputerBook {
	private String name;
	private String scope;
	private String author;
	private int price;
	
	public ComputerBook(String _name,int _price,String _author,String _scope){
		this.name=_name;
		this.price = _price;
		this.author = _author;
		this.scope = _scope;
	}
	
	public String getScope() {
		return this.scope;
	}

	public String getAuthor() {
		return this.author;
	}

	public String getName() {
		return this.name;
	}
	
	public int getPrice() {
		return this.price;
	}

}

           

这也很简单，实现IComputerBook就可以，而BookStore类没有做任何的修改，只是在static静态模块中增加一条数据，如代码所示。书店销售计算机书籍

package ZenofDesignPatterns.ocp.section4;

import java.text.NumberFormat;
import java.util.ArrayList;

/**
 * 书店销售书籍
 */
public class BookStore {
	private final static ArrayList<IBook> bookList = new ArrayList<IBook>();
	
	//静态模块初始化，项目中一般是从持久层初始化产生
	static{
		bookList.add(new NovelBook("设计模式-可复用面向对象软件的基础",3500,"GoF"));
		bookList.add(new NovelBook("天龙八部",3200,"金庸"));//价格乘100了
		bookList.add(new NovelBook("巴黎圣母院",5600,"雨果"));
		bookList.add(new NovelBook("悲惨世界",3500,"雨果"));
		bookList.add(new NovelBook("金瓶梅",4300,"兰陵笑笑生"));
		//增加计算机书籍
		bookList.add(new ComputerBook("Think in Java",4300,"Bruce Eckel","编程语言"));
	}
	
	//模拟书店买书
	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)+"元");
		}
	}
}

           

书店开始销售计算机书籍，运行结果如下所示。

------------书店买出去的书籍记录如下：---------------------
书籍名称：设计模式-可复用面向对象软件的基础	书籍作者：GoF	书籍价格：$35.00元
书籍名称：天龙八部	书籍作者：金庸	书籍价格：$32.00元
书籍名称：巴黎圣母院	书籍作者：雨果	书籍价格：$56.00元
书籍名称：悲惨世界	书籍作者：雨果	书籍价格：$35.00元
书籍名称：金瓶梅	书籍作者：兰陵笑笑生	书籍价格：$43.00元
书籍名称：Think in Java	书籍作者：Bruce Eckel	书籍价格：$43.00元

Process finished with exit code 0
           

如果我是负责维护的，我就非常乐意做这样的事情，简单而且不需要与其他的业务进行耦合。

我唯一需要做的事情就是在原有的代码上添砖加瓦，然后就可以实现业务的变化。

我们来看看这段代码有哪几层含义。

首先，ComputerBook类必须实现IBook的三个方法，是通过IComputerBook接口传递进来的约束，也就是我们制定的IBook接口对扩展类ComputerBook产生了约束力，正是由于该约束力，BookStore类才不需要进行大量的修改。

其次，如果原有的程序设计采用的不是接口，而是实现类，那会出现什么问题呢？

之前是

private final static ArrayList<IBook> bookList = new ArrayList<IBook>();

我们把BookStore类中的私有变量bookList修改一下，如下面的代码所示。

private final static ArrayList<NovelBook> bookList = new ArrayList<NovelBook>();

把原有IBook的依赖修改为对NovelBook实现类的依赖，想想看，我们这次的扩展是否还能继续下去呢？

一旦这样设计，我们就根本没有办法扩展，需要修改原有的业务逻辑（也就是main方法），这样的扩展基本上就是形同虚设。

最后，如果我们在IBook上增加一个方法getScope，是否可以呢？

答案是不可以，因为原有的实现类NovelBook已经在投产运行中，它不需要该方法，而且接口是与其他模块交流的契约，修改契约就等于让其他模块修改。因此，**接口或抽象类一旦定义，就应该立即执行，不能有修改接口的思想，除非是彻底的大返工。**所以，要实现对扩展开放，首要的前提条件就是抽象约束。

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

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

SpringContext的基本配置文件

通过建立一个Father类的子类Son，完成一个新的业务，同时修改SpringContext文件，修改后的文件如代码所示。

扩展后的SpringContext配置文件[插图]通过扩展一个子类，修改配置文件，完成了业务变化，这也是采用框架的好处。

3.制定项目章程

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

约定优于配置

4.封装变化

对变化的封装包含两层含义：

第一，将相同的变化封装到一个接口或抽象类中；

第二，将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中。

封装变化，也就是受保护的变化（protected variations），找出预计有变化或不稳定的点，我们为这些变化点创建稳定的接口，准确地讲是封装可能发生的变化，一旦预测到或“第六感”发觉有变化，就可以进行封装，23个设计模式都是从各个不同的角度对变化进行封装的，要学好这些设计模式。

5、 最佳实践

软件设计最大的难题就是应对需求的变化，但是纷繁复杂的需求变化又是不可预料的。我们要为不可预料的事情做好准备，这本身就是一件非常痛苦的事情，但是大师们还是给我们提出了非常好的6大设计原则以及23个设计模式来“封装”未来的变化。

Single Responsibility Principle：单一职责原则

Open Closed Principle：开闭原则

Liskov Substitution Principle：里氏替换原则

Law of Demeter：迪米特法则

Interface Segregation Principle：接口隔离原则

Dependence Inversion Principle：依赖倒置原则

把这6个原则的首字母（里氏替换原则和迪米特法则的首字母重复，只取一个）联合起来就是SOLID（solid，稳定的），

其代表的含义也就是把这6个原则结合使用的好处：建立稳定、灵活、健壮的设计，而开闭原则又是重中之重，是最基础的原则，是其他5大原则的精神领袖。我们在使用开闭原则时要注意以下几个问题。

●开闭原则也只是一个原则

开闭原则只是精神口号，实现拥抱变化的方法非常多，并不局限于这6大设计原则，但是遵循这6大设计原则基本上可以应对大多数变化。

因此，我们在项目中应尽量采用这6大原则，适当时候可以进行扩充，例如通过类文件替换的方式完全可以解决系统中的一些缺陷。大家在开发中比较常用的修复缺陷的方法就是类替换，比如一个软件产品已经在运行中，发现了一个缺陷，需要修正怎么办？如果有自动更新功能，则可以下载一个.class文件直接覆盖原有的class，重新启动应用（也不一定非要重新启动）就可以解决问题，也就是通过类文件的替换方式修正了一个缺陷，当然这种方式也可以应用到项目中，正在运行中的项目发现需要增加一个新功能，通过修改原有实现类的方式就可以解决这个问题，前提条件是：类必须做到高内聚、低耦合，否则类文件的替换会引起不可预料的故障。

●项目规章

非常重要如果你是一位项目经理或架构师，应尽量让自己的项目成员稳定，稳定后才能建立高效的团队文化，章程是一个团队所有成员共同的知识结晶，也是所有成员必须遵守的约定。优秀的章程能带给项目带来非常多的好处，如提高开发效率、降低缺陷率、提高团队士气、提高技术成员水平，等等。

●预知变化

在实践中过程中，架构师或项目经理一旦发现有发生变化的可能，或者变化曾经发生过，则需要考虑现有的架构是否可以轻松地实现这一变化。架构师设计一套系统不仅要符合现有的需求，还要适应可能发生的变化，这才是一个优良的架构。开闭原则是一个终极目标，任何人包括大师级人物都无法百分之百做到，但朝这个方向努力，可以非常显著地改善一个系统的架构，真正做到“拥抱变化”。

“开-闭”原则，即“对扩展开放，对修改关闭”，指的是在软件设计中，当对某一软件实体进行扩展时，尽量不要去修改原有的软件实体，换句话说就是在不修改原有软件实体的情况下对其进行扩展。这种软件设计方式其实是一种目标，它考虑了软件后期的维护等其他因素。一个软件系统如果可以达到这个目标，那它就是可扩展、易维护的。在软件设计领域中，众多设计模式的应用就是为了达到这个目标。“开-闭”原则是一种很抽象的设计原则，更像是一种倡导的口号，其他设计原则都是为了实现“开-闭”原则的具体原则。“开-闭”原则与其他设计原则就好比抽象父类和子类的关系一样。