本节书摘来自异步社区《Android 源码设计模式解析与实战》一书中的第1章,第1.4节让项目拥有变化的能力——依赖倒置原则,作者 何红辉 , 关爱民,更多章节内容可以访问云栖社区“异步社区”公众号查看
1.4 让项目拥有变化的能力——依赖倒置原则
依赖倒置原则英文全称是Dependence Inversion Principle,缩写是DIP。依赖倒置原则指代了一种特定的解耦形式,使得高层次的模块不依赖于低层次的模块的实现细节的目的,依赖模块被颠倒了。这个概念有点不好理解,这到底是什么意思呢?
依赖倒置原则有以下几个关键点:
(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即可实现缓存功能的替换,这就保证了缓存系统的高可扩展性,有了拥抱变化的能力,这就是依赖倒置原则。从上述几节中我们发现,要想让系统更为灵活,抽象似乎成了我们唯一的手段。