UI 层和逻辑层大家的讨论使我明白在设计多层构造的程序时，层与层之间需要多用接口少用继承，但为何要用接口呢
例如逻辑层直接实例化一种数据访问层的类，然后调用数据访问层中对应的措施返回一种数据源不就可以了吗
这样做也不关接口什么事呀 在企业级程序开发中，一般出于并发的考虑，也许需要很好的可伸缩性(就是可以把一套程序的不一样构造层放在不一样的服务器上，我是这样理解的)，这样的话以 asp
net 的最简单的三层构造举例子，UI 层和逻辑层应当是放在同一台服务器上(我不懂得能不能把它们分到两台服务器中去)，我把它叫做[UI&逻辑服务器]，而数据访问层放在另一台服务器中，我把它叫做[数据访问服务器]，尚有一台是寄存数据库的服务器，这样 UI&逻辑服务器 与 数据访问服务器 中的程序也许就是 2(或以上)个人开发的，两台服务器间的通讯一般是用 WebService，这个我就不说了
按我上面说的，UI&逻辑服务器 中的程序应当是可以直接调用 数据访问服务器 中的类，这自身没什么问题，但到详细开发上时也许就会出问题了，例如 UI&逻辑服务器 中的程序开发人员甲在开始设计的时候需要调用一种 数据访问服务器 中的 GetData()的措施，但这个时候 数据访问服务器 中程序的开发人员乙并不懂得需要增长这个措施，那么甲的工作就继续不下去了，由于他的程序编译不了，假如这个时候甲定义了一种接口，然后在接口的定义中定义一种措施 GetData()，当然这个措施里什么代码都不用写(详细的实现是由乙来做的)，然后乙写的程序都需要继承甲定义的这个接口，当乙的程序在编译的时候就会被提醒哪些措施是必须被实现的，这样一来乙就随时都可以懂得甲需要哪些措施来返回数据了，这样做最起码的好处是不用甲总需要告诉乙需要加哪些措施，并且也不会由于乙对数据访问层程序的误修改(例如误删除了GetData()这个措施)导致 UI&
