本节书摘来自异步社区《Android 源码设计模式解析与实战》一书中的第1章，第1.4节让项目拥有变化的能力——依赖倒置原则，作者 何红辉 , 关爱民，更多章节内容可以访问云栖社区“异步社区”公众号查看

1.4 让项目拥有变化的能力——依赖倒置原则

依赖倒置原则有以下几个关键点：

（1）高层模块不应该依赖低层模块，两者都应该依赖其抽象；

（2）抽象不应该依赖细节；

（3）细节应该依赖抽象。

在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是实现类，实现接口或继承抽象类而产生的类就是细节，其特点就是，可以直接被实例化，也就是可以加上一个关键字new产生一个对象。高层模块就是调用端，低层模块就是具体实现类。依赖倒置原则在 Java语言中的表现就是：模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。这又是一个将理论抽象化的实例，其实一句话就可以概括：面向接口编程，或者说是面向抽象编程，这里的抽象指的是接口或者抽象类。面向接口编程是面向对象精髓之一，也就是上面两节强调的抽象。

如果类与类直接依赖于细节，那么它们之间就有直接的耦合，当具体实现需要变化时，意味着要同时修改依赖者的代码，这限制了系统的可扩展性。在1.3节的图1-3中，ImageLoader直接依赖于MemoryCache，这个MemoryCache是一个具体实现，而不是一个抽象类或者接口。这导致了ImageLoader直接依赖了具体细节，当MemoryCache不能满足ImageLoader而需要被其他缓存实现替换时，此时就必须修改ImageLoader的代码，例如：

public  class  ImageLoader {    // 内存缓存 ( 直接依赖于细节 )    MemoryCache mMemoryCache = new MemoryCache();     // 加载图片到ImageView中    public  void  displayImage(String url, ImageView imageView) {        Bitmap bmp = mMemoryCache.get(url);         if (bmp == null) {            downloadImage(url, imageView);        } else {            imageView.setImageBitmap(bmp);        }    }    public  void   setImageCache(MemoryCache cache) {         mCache = cache ;    }    // 代码省略}

随着产品的升级，用户发现MemoryCache已经不能满足需求，用户需要小民的ImageLoader可以将图片同时缓存到内存和SD卡中，或者可以让用户自定义实现缓存。此时，我们的MemoryCache这个类名不仅不能够表达内存缓存和SD卡缓存的意义，也不能够满足功能。另外，用户需要自定义缓存实现时还必须继承自MemoryCache，而用户的缓存实现可不一定与内存缓存有关，这在命名上的限制也让用户体验不好。重构的时候到了!小民的第一种方案是将MemoryCache修改为DoubleCache，然后在DoubleCache中实现具体的缓存功能。我们需要将ImageLoader修改如下：

public  class  ImageLoader {    // 双缓存 ( 直接依赖于细节 )    DoubleCache mCache = newDoubleCache();    // 加载图片到ImageView中    public  void  displayImage(String url, ImageView imageView) {        Bitmap bmp = mCache.get(url);         if (bmp == null) {            // 异步下载图片            downloadImageAsync(url, imageView);        } else {            imageView.setImageBitmap(bmp);        }    }    public  void   setImageCache(DoubleCache cache) {         mCache = cache ;    }    // 代码省略}

在程序中我们将MemoryCache修改成DoubleCache，然后修改了ImageLoader中缓存类的具体实现，轻轻松松就满足了用户需求。等等！这不还是依赖于具体的实现类（DoubleCache）吗？当用户的需求再次变化时，我们又要通过修改缓存实现类和ImageLoader代码来实现？修改原有代码不是违反了1.3节中的开闭原则吗？小民突然醒悟了过来，低下头思索着如何才能让缓存系统更灵活，拥抱变化……

当然，这些都是在主管给出图1-2以及相应的代码之前，小民体验的煎熬过程。既然是这样，那显然主管给出的解决方案就能够让缓存系统更加灵活。一句话概括起来就是：依赖抽象，而不依赖具体实现。针对于图片缓存，主管建立的ImageCache抽象，该抽象中增加了get和put方法用以实现图片的存取。每种缓存实现都必须实现这个接口，并且实现自己的存取方法。当用户需要使用不同的缓存实现时，直接通过依赖注入即可，保证了系统的灵活性。我们再来简单回顾一下相关代码。

ImageCache缓存抽象：public  interface ImageCache {    public   Bitmap get(String url);    public  void  put(String url, Bitmap bmp);}ImageLoader类：public  class  ImageLoader {    // 图片缓存类，依赖于抽象，并且有一个默认的实现    ImageCache mCache = new MemoryCache();    // 加载图片    public  void  displayImage(String url, ImageView imageView) {        Bitmap bmp = mCache.get(url);         if (bmp == null) {            // 异步加载图片            downloadImageAsync(url, imageView);        } else {            imageView.setImageBitmap(bmp);        }    }    /**     * 设置缓存策略,依赖于抽象     */    public  void  setImageCache(ImageCache cache) {        mCache = cache;    }    // 代码省略}

在这里，我们建立了ImageCache抽象，并且让ImageLoader依赖于抽象而不是具体细节。当需求发生变化时，小民只需要实现ImageCahce类或者继承其他已有的ImageCache子类完成相应的缓存功能，然后将具体的实现注入到ImageLoader即可实现缓存功能的替换，这就保证了缓存系统的高可扩展性，有了拥抱变化的能力，这就是依赖倒置原则。从上述几节中我们发现，要想让系统更为灵活，抽象似乎成了我们唯一的手段。