依赖倒置，控制反转，依赖注入

基于Unity容器的面向接口编程

1：依赖：“依赖描述了两个模型元素之间的关系，如果被依赖的模型元素发生变化就会影响到另一个模型元素。典型的，在类图上，依赖关系表明客户类的操作会调用服务器类的操作。”

2：耦合：“如果改变程序的一个模块要求另一个模块同时发生变化，就认为这两个模块发生了耦合。”

图解耦合

1：依赖耦合度高的程序，模块与模块之间，对象与对象之间，类与类之间

 

开发事例：领导安排工作的时候，程序员小李开发A类，程序员小王开发B类，程序员小刘开发C类.....。一切看起来安排的很完美，大家各司其职，互相开发。但是因为耦合的关系，A类引用(依赖)了B类，B类引用了C类......。如果C类没有开发完成，B类就不能开发，B类不能开发就会导致A类无法开始。当C类是一个业务量很多，逻辑很复杂的类。小刘开发了一半，突然有事请假或者离职。导致A类，B类都无法继续工作，会导致整个项目延迟交付。

日常事例：领导天天催程序员小刘，你快点开发，要不加班吧，不然后面没办法工作啊。

 

 

 

 

IOC

 

什么是IOC：IOC理论提出的观点大体是这样的：借助于“第三方”实现具有依赖关系的对象之间的解耦。如下图：

 

 

 去掉IOC后

 

 

 总结：A,B,C,D类通过IOC容器粘合，降低彼此之间的耦合度。

设计事例举例：

假设我们设计一辆汽车：先设计轮子，然后根据轮子大小设计底盘，接着根据底盘设计车身，最后根据车身设计好整个汽车。这里就出现了一个“依赖”关系：汽车依赖车身，车身依赖底盘，底盘依赖轮子。

 

 

 

 上层建筑依赖下层建筑——每一个类的构造函数都直接调用了底层代码的构造函数。假设我们需要改动一下轮胎（Tire）类，把它的尺寸变成动态的，而不是一直都是30。我们需要这样改：

 

 由于我们修改了轮胎的定义，为了让整个程序正常运行，我们需要做以下改动：

 

 由此我们可以看到，仅仅是为了修改轮胎的构造函数，这种设计却需要修改整个上层所有类的构造函数！在软件工程中，这样的设计几乎是不可维护的——在实际工程项目中，有的类可能会是几千个类的底层，如果每次修改这个类，我们都要修改所有以它作为依赖的类，那软件的维护成本就太高了。所以我们需要进行控制反转（IOC），及上层控制下层，而不是下层控制着上层。 我们用依赖注入（Dependency Injection）这种方式来实现控制反转。所谓依赖注入，就是把底层类作为参数传入上层类，实现上层类对下层类的“控制”。这里我们用构造方法传递的依赖注入方式重新写车类的定义：

 

 这里我们再把轮胎尺寸变成动态的，同样为了让整个系统顺利运行，我们需要做如下修改：

 

 解决方式：Unity容器的面向接口编程

1：搭建Unity框架

2：设计接口类

3：实现接口

4：业务逻辑中调用实现

这样的好处

1：项目负责人只需要定义完整所有的业务逻辑接口类，注释好每个接口中方法的入参，出参，作用。具体的实现交给程序员！这就要求项目负责人，统筹规划业务实现，定义好核心接口，完成后接口后项目负责人后续跟进编码规范，搭建，优化，扩展整个框架和系统。

2:：程序员在业务逻辑中调用的是接口方法，A模块或者类的开发者，不必等待B的完成。因为A中调用的是B的接口，彼此独立开发，互不干扰