浅谈DIP和IOC

追本溯源,不断的回顾基础对我而言是种不错的方式,每次重新回顾这些点往往收获很大.以前,受个人所限,觉得这些理论毫指导价值价值,过于相信实践的的力量,导致自己进步缓慢.其实有些时候,实践更需要站在理论巨人的肩膀,这会让我们少走很多的弯路.

当然具体因人而异.

开发之困

实际开发中最常遇到的问题是类A直接依赖类B.当我们希望将类A修改为依赖类C时,就必须要通过修改类A来实现.这种 情况下类A作为高层的业务模块,负责复杂的业务模块,而类B和类C是底层模块,负责基本的原子操作.实际工程中类A作为业务模块,往往是非常复杂,如果修改类A可能会牵一发而动全身,
,进而带来不必要的业务风险.

那么这类问题该如何应该呢?下来看看大师们提出的原则:依赖倒置.

那什么是依赖倒置呢?

依赖倒置(Dependence Inversion Principle,简称DIP),其定义如下:

High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions.

这句话讲的是什么呢,其实就是以下三点:

• 高层模块不应该直接依赖底层模块,两者都应该依赖抽象.
• 抽象不应依赖细节.
• 细节应该依赖抽象.

看起来有点玄奥,实则不然,重点是理解其中谈到的高层,底层,抽象和细节分别是什么.

高层:通常是系统的负责具体业务逻辑的,它通常依赖一些更为底层的模块;从调用的角度来说,高层是调用者,底层是被调用者.在最常见的用户管理系统中,权限控制逻辑相对数据存储是高层模块,而数据模块则是底层模块,权限控制模块调用数据存储模块.

现在再来看”高层模块不应该依赖底层模块,两者都应该依赖抽象”.放在这里就是,权限控制模块中不应该直接含有数据库链接的对象,同时高层和底层都应该具有其抽象更高层,这样的好处在与”越抽象,越高层,变化的可能性越小”.如果你了解EIT模型,你会发现,EIT模型严格遵循了这一点.

如果说高层和底层是从宏观业务的角度来看,那么抽象和细节则更偏重实现的角度.当然,其实两者的存在紧密的联系,高层通常意味着抽象,底层则意味着细节.

抽象:在java中就是抽象类或者接口,两者无法直接实例化,必须通过其子类.这样的好处在于一个抽象(抽象类或者接口)可能存在多种子类,这中一对多的方式明显比1对1更具有选择性,而更多的选择性意味这灵活.

细节:即具体的实现类,也就是上面提到的子类,可以通过new关键字直接创建响应的实例.

其实不难发现,依赖导致的核心就是面向抽象编程(面向接口属于面向抽象中的一环).
很多人谈到面向接口编程这,觉得已经足够了,实际上我们可以更简练一点:面向抽象编程的就是为了解决对象之间的直接依赖.

相信你现在应该对DIP有认识了,但是对于刚接触的开发者而言,依赖这个词看起并不是那么友好.所以,仍然有必要再对其通俗话.
像小学生造句一样,我们利用依赖这个词造个句子:小颜依赖电脑工作.
这个句子中出现了”小颜”,”电脑”两个对象,这句话的意思也就是,小颜需要主动借助电脑才能工作,换句话说,电脑影响小颜的工作.

在实际生活中,我们几乎每时每刻的都在依赖其他事物(对象)帮我们达成目的,一旦我们所依赖的事物发生改变(事物消失,内部结构变化等等),我们就不得不改变原有做事的方式.
在软件工程中同样如此,每个功能的实现,都意味着不同的对象相互依赖.其中,在某些”坏代码”,你会发现几个变化频繁的对象竟然被直接耦合在一些,这种情况下,后果可想而知.

困难才露尖尖角

到现在,你已经重新温习了dip原则,也许还在努力尝试背下来?现在呢,我希望你忘记上面所说的一切,忘记所谓的准确准则.

现在我们来考虑这样么一种简单的需求:男人开奥迪.相信你很快用OOD的思想,直接划分出Man类和Audi类.那么紧接着,你会写出如下的代码:

public class Audi {