IOS设计模式的六大设计原则之依赖倒置原则(DIP,Dependence Inversion Principle)
定义
高层模块不应该依赖于低层模块，二者都应该依赖于抽象；抽象不应该依赖细节；细节应该依赖抽象。
定义解读
依赖倒置原则在程序编码中经常运用，其核心思想就是面向接口编程，高层模块不应该依赖低层模块(原子操作的模块)，两者都应该依赖于抽象。我们平时常说的“针对接口编程，不要针对实现编程”就是依赖倒转原则的最好体现：接口（也可以是抽象类）就是一种抽象，只要不修改接口声明，大家可以放心大胆调用，至于接口的内部实现则无需关心，可以随便重构。这里，接口就是抽象，而接口的实现就是细节。
如果不管高层模块还是底层模块，它们都依赖于抽象，具体一点就是接口或者抽象类，只要接口是稳定的，那么任何一个的更改都不用担心其他受到影响，这就使得无论高层模块还是低层模块都可以很容易地被复用。
依赖倒转原则其实可以说是面向对象设计的标志，用哪种语言来编写程序不重要，如果编写时考虑的都是如何针对抽象编程而不是针对细节编程，即程序中所有的依赖关系都是终止于抽象类或者接口，那就是面向对象的设计，反之那就是过程化的设计(说这句话可能不怎么好理解，再加上一句话就好理解了：面向对象的设计，出发点就是应对变化的问题)。
再举一个生活中的例子，电脑中内存或者显卡插槽，其实是一种接口，而这就是抽象；只要符合这个接口的要求，无论是用金士顿的内存，还是其它的内存，无论是4G的，还是8G的，都可以很方便、轻松的插到电脑上使用。而这些内存条就是具体实现，就是细节。
错误做法：抽象A依赖于实现细节b
正确做法：抽象A依赖于抽象B，实现细节b实现抽象B
优点
- 代码结构清晰，维护容易。
问题提出
类A直接依赖类B，假如需要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
解决方案
将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。
依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。在C#/Java中，抽象指的是接口或者抽象类；在Objective-C中，抽象指的是委托，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给它们的实现类去完成。
示例
继续发工资的场景：这里，类SalaryManage(类似上面说的类A)负责工资的管理；Director(类似上面说的类B)是总监类，现在我们要通过SalaryManage类来给总监发放工资了，主要代码片段如下所示：
Director.m：
1 - (void)calculateSalary 2 3 { 4 5 NSLog(@"%@总监的工资是10000",_strName); 6 7 }
SalaryManage.m：
1 - (void)calculateSalary:(Director *)director 2 3 { 4 5 [director calculateSalary]; 6 7 }
调用代码：
1 Director *director = [[Directoralloc] init]; 2 3 director.strName = @"张三"; 4 5 SalaryManage *salaryManage = [[SalaryManagealloc] init]; 6 7 [salaryManage calculateSalary:director]; 8 9 [director release]; 10 11 [salaryManage release];
输出结果如下：
2013-11-28 13:51:49.816 DependenceInversionPrinciple[2195:303] 张三总监的工资是10000
这样给总监发放工资的功能已经很好的实现了，现在假设需要给经理发工资，我们发现工资管理类SalaryManage没法直接完成这个功能，需要我们添加新的方法，才能完成。再假设我们还需要给普通员工、财务总监、研发总监等更多的岗位发送工资，那么我们就只能不断的去修改SalaryManage类来满足业务的需求。产生这种现象的原因就是SalaryManage与Director之间的耦合性太高了，必须降低它们之间的耦合度才行。因此我们引入一个委托EmployeeDelegate，它提供一个发放工资的方法定义，如下所示：
1 @protocol EmployeeDelegate <NSObject> 2 3 - (void)calculateSalary; 4 5 @end
然后我们让具体的员工类Director、Manager等都实现该委托方法，如下所示：
修改后的SalaryManage计算工资方法：
1 - (void)calculateSalary:(id<EmployeeDelegate>)employee 2 3 { 4 5 [employee calculateSalary]; 6 7 }
调用代码：
1 Director *director = [[Directoralloc] init]; 2 3 director.strName = @"张三"; 4 5 Manager *manager = [[Manageralloc] init]; 6 7 manager.strName = @"李四"; 8 9 SalaryManage *salaryManage = [[SalaryManagealloc] init]; 10 11 [salaryManage calculateSalary:director]; 12 13 [salaryManage calculateSalary:manager]; 14 15 [director release]; 16 17 [manager release]; 18 19 [salaryManage release];
这样修改后，无论以后怎样扩展其他的岗位，都不需要再修改SalaryManage类了。代表高层模块的SalaryManage类将负责完成主要的业务逻辑(发工资)，如果需要对SalaryManage类进行修改，引入错误的风险极大。所以遵循依赖倒置原则可以降低类之间的耦合性，提高系统的稳定性，降低修改程序造成的风险。
同样，采用依赖倒置原则给多人并行开发带来了极大的便利，比如在上面的例子中，刚开始SalaryManage类与Director类直接耦合时，SalaryManage类必须等Director类编码完成后才可以进行编码和测试，因为SalaryManage类依赖于Director类。按照依赖倒置原则修改后，则可以同时开工，互不影响，因为SalaryManage与Director类一点关系也没有，只依赖于协议(Java和C#中称为接口)EmployeeDelegate。参与协作开发的人越多、项目越庞大，采用依赖导致原则的意义就越重大。
