领略了工厂模式的强大威力，下面继续介绍更加灵活解耦的依赖注入方式，继续回到对于Animal实例化的依赖倒置环节，来看看注入方式下如何通过容器来实现实例创建过程，在此选择Unity基础容器来实现，引入Microsoft.Practices.Unity.dll程序集和Microsoft.Practices.Unity命名空间，然后就可以很容易地通过Unity容器来完成对象创建依赖关系的隔离：
class UnityCreation
{
public static void Main（）
{
IUnityContainer container =new UnityContainer
container.RegisterTYpe<Animal,Dog>（）；
Animal dog = container.Ressolve<Animal>（）；
dog.show（）；
}
}
依赖底层模块，二者都要依赖与抽象；2）抽象不应该依赖细节，细节应该依赖与抽象。
依赖倒置原则(DIP)，通过使代码依赖抽象而不依赖具体实现的方式来达到解耦的目的。让我们先来回顾一下DIP的定义吧：1）高层模块不应该依赖底层模块，二者都要依赖与抽象；2）抽象不应该依赖细节，细节应该依赖与抽象。
简单点说就是：依赖与抽象，或者可以说程序中所有的依赖关系都应该终止于抽象类或或接口。根据这个理解可以得出以下原则：
1.任何变量都不应该持有一个指向具体类中已经实现了的方法。
代码移动可能会改变运算之间的数据依赖关系。因此在每次代码移动之后都必须更新数据依赖关系。
对x的两个赋值 之一可以被向上移动到顶部的基本块，因为这样的转换保持了原程序中的所有依赖关系。但是，一但我们把其中一个赋值语句上移，就不能再移动另一个。更明确地说，我们看到在代码移动之前顶部的基本块的出口处X是不活跃的，但是在移动之后就变得活跃了。如果一个变量在一个程序点上活跃，那么我们不能把对该变量的投机性定值移动到该程序点的前面。
全局调度算法
我们看到代码移动对某些路径有益，但是会损害另外一些路径的性能。好消息是指令并不是生而平等的。实际上，我们知道，一个程序的90%以上的执行时间被花在不到10%的代码上。因此，我们可以把目标确定为使得频繁执行的路径更快运行，虽然有可能降低不频繁路径的运行速度。
并行化或局部性优化经常对原程序中执行的运算重新排序。和所有的优化一样，只有当对运算的重新排序不会改变程序输出时才可以对这些运算重新排序。一般来说，我们不可能深人理解一个程序到底做了什么，代码优化通常选用一个较简单的、保守的测试方法来决定在什么时候可以肯定程序的输出不会受到优化的影响：检查在原程序中和在修改后的程序中，对同一内存位置的各个运算被执行的顺序是否一样。在当前的研究中，我们关注的是数组访问，因此数组元 素就是需要考虑的内存位置。
如果两个访问（不管是读还是写）指向两个不同的位置，显然它们是相互独立的（可以被重 新排序）。另外，读运算不会改变内存的状态，因此各个读运算之间是独立的。如果两个访问指向同一个内存位置并且其中至少有一个写运算，那么就说这两个访问是数据 依赖的。为了保证修改后的程序和原程序做同样的事情，每一对有数据依赖关系的运算在原程 序中的执行顺序必须在新的程序中得到保持。
