面向接口编程综述
在系统分析和架构中，每个层次不是直接向上提供服务（即不是直接实例化在上层中），而是通过定义一组接口，仅向上层暴露接口功能，
上层对下层的依赖，仅仅是接口的依赖而不是具体类的依赖。
这样做的好处是显而易见的，首先对系统灵活性有大的好处，当下层需要改变的时候，只要接口和接口的功能不变，上层不需要做任何修改，甚至可以在不改动上层代码时将下层整个替换掉，
就像我们将一个WD的60G硬盘换成一个希捷的160G的硬盘，计算机其他地方不用做任何改动，而是把原硬盘拔下来、新硬盘插上就行了，因为计算机其他部分不依赖具体硬盘，而只依赖一个IDE接口，只要硬盘实现了这个接口，就可以替换上去。从这里看，程序中的接口和现实中的接口极为相似，所以我一直认为，接口(interface)这个词用的真是神似!
另外关于架构的分层相关的描述
在.NET平台上，比较经典的分层架构是三层架构，从下到上依次是：数据访问层、业务逻辑层、表示层。各层职责如下：
数据访问层：负责与数据源交互，完成数据访问等一系列操作。
业务逻辑层：完成与系统业务有关的逻辑操作。
表示层：负责与用户交互、呈现数据等一切与系统表示有关的操作。
刚才我们说过，分层架构下是向下依赖的（不考虑依赖倒置），也就是业务逻辑层要调用数据访问层完成与数据源有关的操作，而表示层调用业务逻辑层完成业务逻辑工作。但是，表示层对数据访问层是没有依赖的。
在这个架构中，每一层都不是一个类，而是一个类族，例如，在一个CMS系统中，数据访问层可能会有一系列的类，分别负责用户、文章、评论等业务实体的数据访问操作，而业务逻辑层也一样。
如果我们直接依赖，即业务逻辑层实例化数据访问层的类，表示层再实例化业务逻辑层的类，会造成强耦合。如果我想把数据库从SQLServer换成MySQL，则要改变整个业务逻辑层代码，这是个不好的设计。（还记得“开放-关闭”原则吗）
所以，一般的做法是，为数据访问层和业务逻辑层分别定义一族接口，业务逻辑层不依赖具体的数据访问层，而是仅依赖数据访问层的接口族，表示层也一样，依赖业务逻辑层的接口族。
如此一来，当要更换数据库时，我们就不必改写整个业务逻辑层，因为业务逻辑层里根本没有任何数据访问层中的具体类，而全是通过接口实现的。
在.NET中，只要配合配置文件和反射机制，再运用Abstract Factory设计模式，就可以实现“依赖注入”，即在不改动代码的情况下根据配置选择相应的层次组件。这样，我们就可以为不通数据库分别实现数据访问层，也可以编写ORM的数据访问层，甚至是基于XML的，只要实现了数据访问层接口族，就可以和业务逻辑层无缝连接，从而极大提高了软件的灵活性和可维护性。当然要更改业务逻辑层也是一样。
具体可以参考：
http://www.cnblogs.com/leoo2sk/archive/2008/04/14/1151569.html
