OO的精髓在于抽象,抽象可以使调用具体实现的高层不关心具体实现的细节,这样做的好处是降低系统的偶合性,增加系统的灵活性.
比如这种情况:

图1 不成熟的Button和Lamp模型

public class OnButton
{
        private Lamp itsLamp;
        public void poll()
        {
                //some codes...
                itsLamp.turnOn();        
        }
}

这个反案违反了DIP(依赖倒置原则:高层模块不应该以来于低层模块,二者都应该依赖于抽象)。

正在装载数据……

如果从Lamp抽象出一个ButtonServer,那么OnButton就不再依赖于具体的类，他调用ButtonServer的turnOn()方法，但是不用关心打开的是什么。反过来，类似于Lamp的类，比如Door就可以通过继承ButtonServer来重用OnButton.
改进后的结构：


图2 对Lamp应用依赖倒置原则

你可能读完上边的东西，感觉到对自己的设计有所帮助，那么我恭喜你。同时也有必要提醒你一下，因为你可能从一个极端走到了另一个极端，错误的认为系统之间
的依赖都需要的依赖于抽象。
仔细考虑一下为什么我们要抽象出ButtonServer,那是因为我们假设系统中还有其他的类和Lamp类似，因此把开关的操作抽象出来是有意义的。
如果系统中根本不存在这种需要，我觉得抽象是没有意义的。因为这样做提高了系统的复杂性，并且没有提高系统的灵活性。
（我自己对系统灵活性的定义是这样的：一个系统面对一个更改需要付出的劳动力大小。）
这里我想说的是：“不要去过早的考虑可能有的变化，而是在变化来临的时候去应对这个变化，并且修改自己的设计”(出于敏捷思想)

当然上边的工作即使是没有这种变化，但作了这个抽象，还是值得的，提高了系统的灵活性。

但是下边的这种抽象则是一点意义都没有：不依赖于具体的抽象是毫无意义的

我看到过这样一种J2ee设计，特别是在一些讲持久层策略的书上。
他们把负责数据存储操作的类叫做DAO-Data Access Object.高层的业务持久化操作依赖于这些类，但是很多书上都会谈到吧每一个DAO抽象出一个Interface,
这样执行业务的高层就不依赖于实际的DAO,再讲的好听一点就是，你可以随时更换数据库而不需要重新部署，或者你甚至可以用不使用数据库的其他方式来使用
DAO.因此你就会看到你的所有DAO都有了2个类，一个是IxxxDAO(接口)，一个是xxxDAOImp(实现类)。这个时候你或许觉得，恩！一个很好的设计。
但是其实你在面对更改的时候根本没有减少一点劳动力，相反增加的劳动力，比如你现在要添加一个方法到DAO中，你必须修改接口和实现类2个地方。
如果你现在要换数据库，你必须重写全部的DAO实现类，这里和没有接口所付出的劳动力是一模一样的！也就是说，这种解耦合是没有意义的。
为什么会这样呢？这是因为这里的抽象没有依赖于某一个具体的东西，仔细想一下就能明白不依赖于具体的抽象是毫无意义的。比如我们上边Button的例子，
对于抽象出ButtonServer这个接口的意义是因为有OnButton有一个poll的具体方法。这里重用了OnButton类。但是对与每一个DAO抽象出
一个Interface则没有重用到任何东西，即抽象不依赖于任何具体的东西，这样的抽象毫无意义。
怎么改进呢？我认为，如果考虑到更换数据库的可能，可以使用策略模式，把获得数据库连接的方法作为一个抽象策略，这样就重用了获得连接以后的操作。
如果要应对不同数据库的方言，应该抽象出一个不同数据库查询语言生成的策略模式，这样还是重用了DAO中其他的东西。这种抽象是有意义的。
而一个DAO一个Interface毫无意义。
我以前犯过这样的错误。现在看到很多人还在跟我一样犯这个错误，并且完全没有意识到这个错误，所以写了这篇文章。希望对你有所帮助。 

本文来源：http://blog.csdn.net/solonote/archive/2007/06/25/1666229.aspx