依赖倒转原则
在大话设计模式这本书中,作者通过电话修电脑这个例子引入了面向对象设计的基本原则之一:依赖倒转原则
。
概念
依赖倒转原则是面向对象设计的基本原则之一,它用于减少类之间的耦合,提高系统的灵活性和可维护性。在书中,依赖倒转原则的原话解释是抽象不应该依赖细节,细节应该依赖于抽象
。它的主要内容可以分为两个部分:
- 高层模块不应该依赖低层模块。两者都应该依赖其抽象。
- 抽象不应该依赖于细节。细节应该依赖于抽象。
简单点说,就是我们在编程的时候要依赖于抽象(接口或抽象类),不要依赖于具体的类(对象)。
这一原则与我们前文中所讲解的里氏代换原则相辅相成,当我们满足里氏代换原则时,子类能够完全替换父类。而满足依赖倒转原则时,细节依赖于抽象(抽象类一般是父类)。因此当同时遵循这两个原则的时候,我们的代码就能够通过子类灵活的进行扩展。
例子
光讲上面的概念可能难以理解其中的含义,这里举一个具体的例子。
- 假设我们正在开发一个新闻应用,这个应用有一个
NewsService
类,它负责从不同的新闻源获取新闻。一开始,我们只从网络获取新闻,所以我们可能会有以下的设计:
class NewsService {NetworkNewsFetcher fetcher;NewsService() {this.fetcher = new NetworkNewsFetcher();}List<News> getNews() {return fetcher.fetch();}
}class NetworkNewsFetcher {List<News> fetch() {// fetch news from the network}
}
在这个设计中,NewsService
直接依赖于NetworkNewsFetcher
,这意味着如果我们想从其他来源(如本地文件)获取新闻,我们就需要修改NewsService
的代码。
现在,让我们按照依赖倒转原则来重新设计这个系统:
interface NewsFetcher {List<News> fetch();
}class NewsService {NewsFetcher fetcher;NewsService(NewsFetcher fetcher) {this.fetcher = fetcher;}List<News> getNews() {return fetcher.fetch();}
}class NetworkNewsFetcher implements NewsFetcher {@Overridepublic List<News> fetch() {// fetch news from the network}
}class LocalNewsFetcher implements NewsFetcher {@Overridepublic List<News> fetch() {// fetch news from a local file}
}
- 在这个新的设计中,
NewsService
依赖于NewsFetcher
接口,而不是具体的NetworkNewsFetcher
类。这样,我们就可以在不修改NewsService
的代码的情况下,通过添加新的NewsFetcher
实现(如LocalNewsFetcher
)来扩展系统的功能。这个例子是通过代码来解释依赖倒转原则,能够帮助有一定编程基础的同学能够更加清晰地体会到依赖倒转原则的优点。
优缺点
在大话设计模式中,有这样一句话:可以把PC电脑理解成是大的软件系统,任何部件如CPU、内存、硬盘、显卡等都可以理解为程序中封装的类或程序集,由于PC易插拔的方式,那么不管哪一个出问题,都可以在不影响别的部件的前提下进行修改或替换。
在这句话中 PC电脑
依赖于CPU、内存、硬盘、显卡等
硬件设备,而这些硬件损坏的时候,我们能够很方便的对其进行更换,这就依赖于PC易插拔的方式
。我们可以思考一个这样的问题,PC易插拔的方式
是怎么做到的?其实就是因为它遵循了依赖倒置原则,严格意义上来讲,PC电脑
所依赖的并不是具体的某一块CPU、内存、硬盘、显卡等
硬件设备,而是依赖能够插进主板插槽
的硬件设备。而这个主板预留出的插槽
其实就是我们前面所谓的“抽象”(接口或抽象类),只有主板依赖于插槽
,这些硬件的生产厂商,再根据插槽
的形状去做对应的硬件,才能够实现PC易插拔
。否则, 如果PC依赖的具体的某一块CPU、内存、硬盘、显卡等
硬件设备,那如果硬件设备坏了,就得整个PC都换掉,因为PC只“用得惯”这一块硬件。
因此,总结一下依赖倒转原则的优点:它使我们的代码更加灵活,更容易扩展和维护。