网站建设自我总结,电商网站有哪些类型,公司装修便宜,dedecms医院网站wap模板(橙色)4/512345定义#xff1a;
高层模块不应该依赖低层模块#xff0c;二者都应该依赖其抽象#xff1b;抽象不应该依赖细节#xff1b;细节应该依赖抽象。 问题由来#xff1a;类A直接依赖类B#xff0c;假如要将类A改为依赖类C#xff0c;则必须通过修改类A的代码来达成。这种场景下…定义
高层模块不应该依赖低层模块二者都应该依赖其抽象抽象不应该依赖细节细节应该依赖抽象。 问题由来类A直接依赖类B假如要将类A改为依赖类C则必须通过修改类A的代码来达成。这种场景下类A一般是高层模块负责复杂的业务逻辑类B和类C是低层模块负责基本的原子操作假如修改类A会给程序带来不必要的风险。 解决方案将类A修改为依赖接口I类B和类C各自实现接口I类A通过接口I间接与类B或者类C发生联系则会大大降低修改类A的几率。 依赖倒置原则基于这样一个事实相对于细节的多变性抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在Java中抽象指的是接口或者抽象类细节就是具体的实现类使用接口或者抽象类的目的是制定好规范和契约而不去涉及任何具体的操作把展现细节的任务交给他们的实现类去完成。 依赖倒置原则的核心思想是面向接口编程我们依旧用一个例子来说明面向接口编程比相对于面向实现编程好在什么地方。场景是这样的母亲给孩子讲故事只要给她一本书她就可以照着书给孩子讲故事了。代码如下 [java] view plaincopy class Book{ public String getContent(){ return 很久很久以前有一个阿拉伯的故事……; } } class Mother{ public void narrate(Book book){ System.out.println(妈妈开始讲故事); System.out.println(book.getContent()); } } public class Client{ public static void main(String[] args){ Mother mother new Mother(); mother.narrate(new Book()); } } 运行结果 妈妈开始讲故事 很久很久以前有一个阿拉伯的故事…… 运行良好假如有一天需求变成这样不是给书而是给一份报纸让这位母亲讲一下报纸上的故事报纸的代码如下 [java] view plaincopy class Newspaper{ public String getContent(){ return 林书豪387领导尼克斯击败湖人……; } } 这位母亲却办不到因为她居然不会读报纸上的故事这太荒唐了只是将书换成报纸居然必须要修改Mother才能读。假如以后需求换成杂志呢换成网页呢还要不断地修改Mother这显然不是好的设计。原因就是Mother与Book之间的耦合性太高了必须降低他们之间的耦合度才行。 我们引入一个抽象的接口IReader。读物只要是带字的都属于读物 [java] view plaincopy interface IReader{ public String getContent(); } Mother类与接口IReader发生依赖关系而Book和Newspaper都属于读物的范畴他们各自都去实现IReader接口这样就符合依赖倒置原则了代码修改为 [java] view plaincopy class Newspaper implements IReader { public String getContent(){ return 林书豪179助尼克斯击败老鹰……; } } class Book implements IReader{ public String getContent(){ return 很久很久以前有一个阿拉伯的故事……; } } class Mother{ public void narrate(IReader reader){ System.out.println(妈妈开始讲故事); System.out.println(reader.getContent()); } } public class Client{ public static void main(String[] args){ Mother mother new Mother(); mother.narrate(new Book()); mother.narrate(new Newspaper()); } } 运行结果 妈妈开始讲故事 很久很久以前有一个阿拉伯的故事…… 妈妈开始讲故事 林书豪179助尼克斯击败老鹰…… 这样修改后无论以后怎样扩展Client类都不需要再修改Mother类了。这只是一个简单的例子实际情况中代表高层模块的Mother类将负责完成主要的业务逻辑一旦需要对它进行修改引入错误的风险极大。所以遵循依赖倒置原则可以降低类之间的耦合性提高系统的稳定性降低修改程序造成的风险。 采用依赖倒置原则给多人并行开发带来了极大的便利比如上例中原本Mother类与Book类直接耦合时Mother类必须等Book类编码完成后才可以进行编码因为Mother类依赖于Book类。修改后的程序则可以同时开工互不影响因为Mother与Book类一点关系也没有。参与协作开发的人越多、项目越庞大采用依赖导致原则的意义就越重大。现在很流行的TDD开发模式就是依赖倒置原则最成功的应用。 传递依赖关系有三种方式以上的例子中使用的方法是接口传递另外还有两种传递方式构造方法传递和setter方法传递相信用过spring框架的对依赖的传递方式一定不会陌生。 在实际编程中我们一般需要做到如下3点
低层模块尽量都要有抽象类或接口或者两者都有。变量的声明类型尽量是抽象类或接口。使用继承时遵循里氏替换原则。 依赖倒置原则的核心就是要我们面向接口编程理解了面向接口编程也就理解了依赖倒置。
