最基础设计原则 开闭原则

2.1 通过内存缓存解决了每次从网络加载图片的问题，但是Android应用的内存很有限，且具有易失性，即当应用重新启动之后，原来已经加载过的图片将会丢失，这样重启之后就需要重新下载！这又会导致加载缓慢、耗费用户流量问题。考虑引入SD卡缓存，这样下载过的图片就会缓存到本地，即使重启应用也不需要重新下载了。

2.2 新增 DisckCache 类，在ImageLoader中通过useDiskCache方法可以让用户设置不同的缓存。有两种缓存一种是SD卡缓存一种是内存缓存，这里会碰到一个明显的问题:就是使用内存缓存时用户就不能使用SD卡缓存。类似地，使用SDK缓存时用户就不能使用内存缓存。用户需要这两种策略的综合，首先缓存优先使用内存缓存，如果内存缓存没有图片再使用SD卡缓存，如果SD卡中也没有图片最后才从网络上获取，这才是最好的缓存策略。

if(isUseDoubleCache){

bmp = mDoubleCache.get(url);

}else if(isUseDiskCache){

bmp = mDiskCache.get(url);

}else{

bmp = mImageCache.get(url);

}

if(bmp!=null)

imageView.setImageBitmap(bmp);

上面的代码是解决了获取图片时先从内存缓存中获取，如果内存中没有缓存该图片，再从SD卡中获取。缓存图片也是在内存和SD卡中都缓存一份。没有缓存，则提交给线程池进行一步下载图片。

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

软件中的对象(类、模块、函数等)应该对于扩展是开放的，但是对于修改时封闭的，这就是开放关闭原则。也就是说，当软件需要变化是，我们应该尽量通过扩展方式来实现变化，而不是通过修改已有的代码来实现。设置一新的方法注入缓存实现:public void setImageCache(ImageCache cache){

mImageCache = cache;

}

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

public interface ImageCache{

public Bitmap get(String url);

public void put(String url,Bitmap bmp);

}

ImageLoader类中增加了一个setImageCache(ImageCache cache)函数，用户可以通过该函数设置缓存实现，也就是通常说的依赖注入。通过setImageCache 方法注入不同的缓存实现，这样不仅能够使ImageLoader更简单、健壮，也使得ImageLoader的课扩展性、灵活性更高。MemoryCache、DiskCache、DoubleCache缓存图片的具体实现完全不一样，但是，它们的一个特点是，都实现了ImageCache接口。当用户需要自定义实现缓存策略时，只需要新建一个实现ImageCache接口的类，然后构造该类的对象，并且通过setImageCache(ImageCache cache)注入到ImageLoader中，这样ImageLoader就实现了千变万化的缓存策略，且扩展这些缓存策略并不会导致ImageLoader类的修改。

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