JAVA中的依赖倒原则
美国法律有一条最基本的准则就是“人人平等”，我们不去管它是经过什么样的斗争、什么样的流血牺牲换来的，只把它理解为一个JAVA方法，该方法定义如下：
public final boolean 人人平等(人1，人2){
return true;
}
虽然各个州的法律有可能不同，如美国基本法，纽约有可能叫纽约基本法，他们应该是这样一种关系：纽约基本法继承美国基本法，但是不允许对该方法进行重写。
在纽约执行法很的时候，采用：
美国基本法 = new 纽约基本法
任何地方调用"人人平等"这个方法，都是返回"true"，也就是人人平等的原则在任何地方都不可能被改变，这是宏观决定微观，而不会因为纽约而变成男人与女人的不相等。
如某国也有基本法，也有人人平等的方法。定义应该如下：
public boolean 人人平等(人1，人2){
return true;
}
如某国的某地也有基本法，某地基本法也是继承于某国基本法，但是因为"人人平等"这个方法不是final类型的，因而可能被改写，某地执行的时候，可能采用：
某国基本法 = new 某地基本法
或
某地基本法 = new 某地基本法
说不定某地基本法中在继承某国基本法的时候，就将"人人平等"这个方法给重写了，改成了：
public boolean 人人平等(人1，人2){
if(人1==某地人 && 人2==某地人){
if(人1与人2属性于同一阶层){
if(人1与人2除了不是同一个人基它都相同){
if(无人为其它情况发生){
return true;
}else{
return false;
}
}else{
return false;
}
}else{
return false;
}
}else{
return false;
}
}
再来说说依赖倒转原则，根据《JAVA与模式》中的说的：
抽象层次包含的是应用系统的商务逻辑和宏观的、对整个系统来说重要的战略性决定，是必然性的体现；而具体层次则含有一些次要的与实现有关的算法和逻辑，以及战术性的决定，带有相当大的偶然性选择。具体层次的代码是会经常有变动的，不能避免出现错误。抽象层次依赖于具体层次，使用具体层次的细节的算法变化立即影响到抽象层次的宏观的商务逻辑，导致微观决定宏观，战术决定战略，偶然决定必然，这是很荒唐的事情。
看了这个也就知道为什么以后写代码的时候，多用用：
抽象逻辑 = new 具体逻辑
尽量少用：
具体逻辑 = new 具体逻辑
这个也就是现在比较提倡的面向接口编程，再举一个面向接口编程比较实用的例子：
平时用List应该比较多，List本身就是一个继承于Collection的接口，可以这样用：
List list=new Vector();
这样声明的这个List其实是一个Vector类型，因为Vector是其子类，根据里氏代换原则，能够接受父类的地方，都可以接受子类。此时的List是同步的，当然也因此会受到一定的性能影响了。如果以后换了一个不需要同步的环境，只需要将以上代码改为如：
List list=new ArrayList();
其它的任何代码都不需要修改，此时的List的实际类型就为ArrayList了。
从此一点，可以看出面向接口编程为什么是设计人员的珍爱了，因为他们提供了接口之后，实施人员根据该接口去实现具体类，就不担心实施人员破坏原有程序的完整性，设计人员永远只关心接口中的方法，具体类中的辅助方法不用去担心。但是这是通过额外的代价换来的，如增加JAVA类等，如果抽象类能够带来较少的效率，采用具体耦合反而是更好的选择，如工具类。