本节书摘来自异步社区《Android 源码设计模式解析与实战》一书中的第1章，第1.2节让程序更稳定、更灵活——开闭原则，作者 何红辉 , 关爱民，更多章节内容可以访问云栖社区“异步社区”公众号查看

1.2　让程序更稳定、更灵活——开闭原则
开闭原则的英文全称是Open Close Principle，缩写是OCP，它是Java世界里最基础的设计原则，它指导我们如何建立一个稳定的、灵活的系统。开闭原则的定义是：软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是，对于修改是封闭的。在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会将错误引入原本已经经过测试的旧代码中，破坏原有系统。因此，当软件需要变化时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。当然，在现实开发中，只通过继承的方式来升级、维护原有系统只是一个理想化的愿景，因此，在实际的开发过程中，修改原有代码、扩展代码往往是同时存在的。

软件开发过程中，最不会变化的就是变化本身。产品需要不断地升级、维护，没有一个产品从第一版本开发完就再没有变化了，除非在下个版本诞生之前它已经被终止。而产品需要升级，修改原来的代码就可能会引发其他的问题。那么，如何确保原有软件模块的正确性，以及尽量少地影响原有模块，答案就是，尽量遵守本章讲述的开闭原则。

勃兰特·梅耶在1988年出版的《面向对象软件构造》一书中提出这一原则——开闭原则。这一想法认为，程序一旦开发完成，程序中一个类的实现只应该因错误而被修改，新的或者改变的特性应该通过新建不同的类实现，新建的类可以通过继承的方式来重用原类的代码。显然，梅耶的定义提倡实现继承，已存在的实现类对于修改是封闭的，但是新的实现类可以通过覆写父类的接口应对变化。

说了这么多，想必大家还是半懂不懂，还是让我们以一个简单示例说明一下。

在对ImageLoader进行了一次重构之后，小民的这个开源库获得了一些用户，小民第一次感受成功的快乐，对开源的热情也越发高涨起来！通过动手实现一些开源库来深入学习相关技术，不仅能够提升自我，也能更好地将这些技术运用到工作中，从而开发出更稳定、更优秀的应用，这就是小民的真实想法。

小民第一轮重构之后的ImageLoader职责单一、结构清晰，不仅获得了主管的一点肯定，还得到了用户的夸奖，算是个不错的开始。随着用户的增多，有些问题也暴露出来了，小民的缓存系统就是大家“吐槽”最多的地方。通过内存缓存解决了每次从网络加载图片的问题，但是，Android应用的内存很有限，且具有易失性，即当应用重新启动之后，原来已经加载过的图片将会丢失，这样重启之后就需要重新下载！这又会导致加载缓慢、耗费用户流量的问题。小民考虑引入SD卡缓存，这样下载过的图片就会缓存到本地，即使重启应用也不需要重新下载了。小民在和主管讨论了该问题之后就投入了编程中，下面就是小民的代码。

DiskCache.java类，将图片缓存到SD卡中：

public　class　DiskCache {
　　static　String cacheDir = "sdcard/cache/";
　　// 从缓存中获取图片
　　public　 Bitmap get(String url) {
　　　　return　BitmapFactory.decodeFile(cacheDir + url);
　　}

　　// 将图片缓存到内存中
　　public　void　put(String url, Bitmap bmp) {
　　　　FileOutputStream fileOutputStream = null;
　　　　try {
　　　　　　fileOutputStream = new FileOutputStream(cacheDir + url);
　　　　　　bmp.compress(CompressFormat.PNG, 100, fileOutputStream);
　　　　} catch (FileNotFoundException e) {
　　　　　　　　 e.printStackTrace();
　　　　} final ly {
　　　　　　if (fileOutputStream != null) {
　　　　　　　　try {
　　　　　    　　　fileOutputStream.close();
　　　　　　　　} catch (IOException e) {
　　　    　　　　　e.printStackTrace();
　　　　　　　　}
　　　　　　}
　　　　}
　　}
}
因为需要将图片缓存到SD卡中，所以，ImageLoader代码有所更新，具体代码如下：

public　class ImageLoader {
　　// 内存缓存
　　ImageCache mImageCache = new ImageCache();
　　// SD卡缓存
　　DiskCache mDiskCache = new DiskCache();
　　// 是否使用SD卡缓存
　　boolean isUseDiskCache = false;
　　// 线程池,线程数量为CPU的数量
　　ExecutorService mExecutorService = Executors.newFixedThreadPool (Runtime.  
　　getRuntime().availableProcessors());

　　public　void displayImage(final String url, final ImageView imageView) {
　　　　// 判断使用哪种缓存
　　　　Bitmap bitmap = isUseDiskCache ? mDiskCache.get(url) : mImageCache.get (url);
　　　　if (bitmap != null) {
　　　　　　imageView.setImageBitmap(bitmap);
　　　　　　return;
　　　　　　}
　　　　　// 没有缓存，则提交给线程池进行下载
　　}

　　public　void useDiskCache(boolean useDiskCache) {
　　　　isUseDiskCache = useDiskCache ;
　　}
}

从上述的代码中可以看到，仅仅新增了一个DiskCache类和往ImageLoader类中加入了少量代码就添加了SD卡缓存的功能，用户可以通过useDiskCache方法来对使用哪种缓存进行设置，例如：

ImageLoader imageLoader = new ImageLoader() ;
 // 使用SD卡缓存
imageLoader.useDiskCache(true);
// 使用内存缓存
imageLoader.useDiskCache(false);

通过useDiskCache方法可以让用户设置不同的缓存，非常方便啊！小民对此很满意，于是提交给主管做代码审核。“小民，你思路是对的，但是有些明显的问题，就是使用内存缓存时用户就不能使用SD卡缓存。类似地，使用SD卡缓存时用户就不能使用内存缓存。用户需要这两种策略的综合，首先缓存优先使用内存缓存，如果内存缓存没有图片再使用SD卡缓存，如果SD卡中也没有图片最后才从网络上获取，这才是最好的缓存策略。”主管的解释真是一针见血，小民这时才如梦初醒，刚才还得意洋洋的脸上突然有些泛红……

于是小民按照主管的指点新建了一个双缓存类DoubleCache，具体代码如下：

/**
 * 双缓存。获取图片时先从内存缓存中获取，如果内存中没有缓存该图片，再从SD卡中获取。
 *　缓存图片也是在内存和SD卡中都缓存一份
 */
public　class　DoubleCache {
　　 ImageCache mMemoryCache = new ImageCache();
　　 DiskCache mDiskCache = new DiskCache();

　　// 先从内存缓存中获取图片，如果没有，再从SD卡中获取
　　public　 Bitmap get(String url) {
　　　　Bitmap bitmap = mMemoryCache.get(url);
　　　　if (bitmap == null) {
　　　　　　bitmap = mDiskCache.get(url);
　　　　}
　　　　return　bitmap;
　　}

　　// 将图片缓存到内存和SD卡中
　　public　void　put(String url, Bitmap bmp) {
　　　　mMemoryCache.put(url, bmp);
　　　　mDiskCache.put(url, bmp);
　　}
}
我们再看看最新的ImageLoader类，代码更新也不多：

public　class ImageLoader {
　　// 内存缓存
　　ImageCache mImageCache = new ImageCache();
　　// SD卡缓存
　　DiskCache mDiskCache = new DiskCache();
　　// 双缓存
　　DoubleCache mDoubleCache = new DoubleCache() ;
　　// 使用SD卡缓存
　　boolean isUseDiskCache = false;
　　// 使用双缓存
　　boolean isUseDoubleCache = false;
　　// 线程池,线程数量为CPU的数量
　　ExecutorService mExecutorService = Executors.newFixedThreadPool 
　　(Runtime.getRuntime().availableProcessors());

　　public　void displayImage(final String url, final ImageView imageView) {
　　　　Bitmap bmp = null;
　　　　if (isUseDoubleCache) {
　　　　　　　 bmp = mDoubleCache.get(url);
　　　　} else if (isUseDiskCache) {
　　　　　　　 bmp = mDiskCache.get(url);
　　　　 } else {
　　　　　　bmp = mImageCache.get(url);
　　　}
　　if ( bmp != null ) {
　　　　imageView.setImageBitmap(bmp);
　　}
　　// 没有缓存，则提交给线程池进行异步下载图片
　　}

　　public　void useDiskCache(boolean useDiskCache) {
　　　　isUseDiskCache = useDiskCache ;
　　}

　　public　void useDoubleCache(boolean useDoubleCache) {
　　　　isUseDoubleCache = useDoubleCache ;
　　}
}

通过增加短短几行代码和几处修改就完成了如此重要的功能。小民已越发觉得自己Android开发已经到了得心应手的境地，顿时感觉一阵春风袭来，小民感觉今天天空比往常敞亮许多。

“小民，你每次加新的缓存方法时都要修改原来的代码，这样很可能会引入Bug，而且会使原来的代码逻辑变得越来越复杂。按照你这样的方法实现，用户也不能自定义缓存实现呀！”到底是主管水平高，一语道出了小民这缓存设计上的问题。

我们还是来分析一下小民的程序。小民每次在程序中加入新的缓存实现时都需要修改ImageLoader类，然后通过一个布尔变量来让用户选择使用哪种缓存，因此，就使得在ImageLoader中存在各种if-else判断语句，通过这些判断来确定使用哪种缓存。随着这些逻辑的引入，代码变得越来越复杂、脆弱，如果小民一不小心写错了某个if条件（条件太多，这是很容易出现的），那就需要更多的时间来排除，整个ImageLoader类也会变得越来越臃肿。最重要的是，用户不能自己实现缓存注入到ImageLoader中，可扩展性差，可扩展性可是框架的最重要特性之一。

“软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是对于修改是封闭的，这就是开放——关闭原则。也就是说，当软件需要变化时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。”小民的主管补充到，小民听得云里雾里的。主管看小民这等反应，于是亲自“操刀”，为他画下了图1-2所示的UML图。

小民看到图1-2似乎明白些什么，但又不是很明确如何修改程序。主管看到小民这般模样，只好亲自上阵，带着小民把ImageLoader程序按照图1-2进行了一次重构，具体代码如下：

public　class ImageLoader {
　　// 图片缓存
　　ImageCache mImageCache = new MemoryCache();
　　// 线程池,线程数量为CPU的数量
　　ExecutorService mExecutorService = Executors.newFixedThreadPool 
　　(Runtime.getRuntime().availableProcessors());

　　// 注入缓存实现
　　public　void setImageCache(ImageCache cache) {
　　　　mImageCache = cache;
　　 }

　　public　void displayImage(String imageUrl, ImageView imageView) {
　　Bitmap bitmap = mImageCache.get(imageUrl);
　　　　if (bitmap != null) {
　　　　　　imageView.setImageBitmap(bitmap);
　　　　　　return;
　　　　　 }
　　　　　　// 图片没缓存，提交到线程池中下载图片
　　　　submitLoadRequest(imageUrl, imageView);
　　 }

　　private void submitLoadRequest(final String imageUrl,
　　final ImageView imageView) {
　　　　imageView.setTag(imageUrl);
　　　　mExecutorService.submit(new Runnable() {

　　　　　　@Override
　　　　　　public　void run() {
　　　　　　　　Bitmap bitmap = downloadImage(imageUrl);
　　　　　　　　if (bitmap == null) {
　　　　　　　　　　return;
　　　　　　　　}
　　　　　　　　if (imageView.getTag().equals(imageUrl)) {
　　　　　　　　　　imageView.setImageBitmap(bitmap);
　　　　　　}
　　　　　　mImageCache.put(imageUrl, bitmap);
　　　　　　}
　　　　});
　　}

　　public　Bitmap downloadImage(String imageUrl) {
　　　　Bitmap bitmap = null;
　　　　try {
　　　　　　URL url = new URL(imageUrl);
　　　　　　final HttpURLConnection conn = (HttpURLConnection) url.openConnection();
　　　　　　bitmap = BitmapFactory.decodeStream(conn.getInputStream());
　　　　　　conn.disconnect();
　　　　} catch (Exception e) {
　　　　e.printStackTrace();
　　　　}

　　return bitmap;
　　}
}

经过这次重构，没有了那么多的if-else语句，没有了各种各样的缓存实现对象、布尔变量，代码确实清晰、简单了很多，小民对主管的崇敬之情又“泛滥”了起来。需要注意的是，这里的ImageCache类并不是小民原来的那个ImageCache，这次重构程序，主管把它提取成一个图片缓存的接口，用来抽象图片缓存的功能，我们看看该接口的声明：

public　interface ImageCache {
　　public　 Bitmap get(String url);
　　public　void　put(String url, Bitmap bmp);
}

ImageCache接口简单定义了获取、缓存图片两个函数，缓存的key是图片的url，值是图片本身。内存缓存、SD卡缓存、双缓存都实现了该接口，我们看看这几个缓存实现：

// 内存缓存MemoryCache类
public　class　MemoryCache implements ImageCache {
　　private　LruCache<String, Bitmap> mMemeryCache;

　　public　MemoryCache() {
　　　　// 初始化LRU缓存
　　}

　　 @Override
　　public　 Bitmap get(String url) {
　　　　return　mMemeryCache.get(url);
　　}

　　@Override
　　public　void　put(String url, Bitmap bmp) {
　　　　mMemeryCache.put(url, bmp);
　　 }
}

// SD卡缓存DiskCache类
public　class　DiskCache implements ImageCache {
　　 @Override
　　public　 Bitmap get(String url) {
　　　　return null/* 从本地文件中获取该图片 */;
　　}

　　@Override
　　public　void　put(String url, Bitmap bmp) {
　　　　// 将Bitmap写入文件中
　　}
}

// 双缓存DoubleCache类
public　class　DoubleCache implements ImageCache{
　　ImageCache mMemoryCache = new MemoryCache();
　　ImageCache mDiskCache = new DiskCache();

　　// 先从内存缓存中获取图片，如果没有，再从SD卡中获取
　　public　Bitmap get(String url) {
　　　　Bitmap bitmap = mMemoryCache.get(url);
　　　　if (bitmap == null) {
　　　　　　bitmap = mDiskCache.get(url);
　　　　}
　　　　return bitmap;
　　 }

　　// 将图片缓存到内存和SD卡中
　　public　void　put(String url, Bitmap bmp) {
　　　　mMemoryCache.put(url, bmp);
　　　　mDiskCache.put(url, bmp);
　　}
}

细心的读者可能注意到了，ImageLoader类中增加了一个etImageCache（ImageCache cache）函数，用户可以通过该函数设置缓存实现，也就是通常说的依赖注入。下面就看看用户是如何设置缓存实现的：

ImageLoader imageLoader = new ImageLoader() ;
　　　　// 使用内存缓存
imageLoader.setImageCache(new MemoryCache());
　　　　// 使用SD卡缓存
imageLoader.setImageCache(new DiskCache());
　　　　// 使用双缓存
imageLoader.setImageCache(new DoubleCache());
　　　　// 使用自定义的图片缓存实现
imageLoader.setImageCache(new ImageCache() {

　　 @Override
　　 public　void　put(String url, Bitmap bmp) {
　　　　　　　　// 缓存图片
　　　　　　}

　　　　　　@Override
　　　　　　public　Bitmap get(String url) {
　　　　　　　　return　null/*从缓存中获取图片*/;
　　　　　　}
　　　　});

在上述代码中，通过setImageCache（ImageCache cache）方法注入不同的缓存实现，这样不仅能够使ImageLoader更简单、健壮，也使得ImageLoader的可扩展性、灵活性更高。MemoryCache、DiskCache、DoubleCache缓存图片的具体实现完全不一样，但是，它们的一个特点是，都实现了ImageCache接口。当用户需要自定义实现缓存策略时，只需要新建一个实现ImageCache接口的类，然后构造该类的对象，并且通过setImageCache（ImageCache cache）注入到ImageLoader中，这样ImageLoader就实现了千变万化的缓存策略，且扩展这些缓存策略并不会导致ImageLoader类的修改。经过这次重构，小民的ImageLoader已经基本算合格了。咦！这不就是主管说的开闭原则么！“软件中的对象（类、模块、函数等）应该对于扩展是开放的，但是，对于修改是封闭的。而遵循开闭原则的重要手段应该是通过抽象……”小民细声细语地念叨着，陷入了思索中……

开闭原则指导我们，当软件需要变化时，应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。这里的“应该尽量”4个字说明OCP原则并不是说绝对不可以修改原始类的。当我们嗅到原来的代码“腐化气味”时，应该尽早地重构，以便使代码恢复到正常的“进化”过程，而不是通过继承等方式添加新的实现，这会导致类型的膨胀以及历史遗留代码的冗余。我们的开发过程中也没有那么理想化的状况，完全地不用修改原来的代码，因此，在开发过程中需要自己结合具体情况进行考量，是通过修改旧代码还是通过继承使得软件系统更稳定、更灵活，在保证去除“代码腐化”的同时，也保证原有模块的正确性。