基于接口开发介绍
基于接口编程的本质是分离对象的实现与使用者之间的关系，即变更以下对象结构的依赖变化：
这样说的好处是客户对象依赖于服务接口，即在开发过程中我们只关注于服务接口的定义，而不关注于服务对象的具体实现，客户对象只有在运行期才通过解耦与后期绑定辅助工具（类）与具体的服务实现对象动态的建议依赖。
这样做的好处是很显然的，从技术上讲，如果把服务接口与服务实现分别放在不同的组件之中，那么修改了服务实现组件，我们不用重新编译客户组件，在软件工程上的带给我们的好处是，服务接口与服务组件即接口定义与实现可以相分离，可以交给不同的人去做，同时，我们可以通过这种结构实现在运行期通过动态配置以替换不同的服务组件实现。
一个应用场景及案例
比如我们要开发一套HIS系统，需要集成医疗保险，但是不同的地区使用不同的医疗保险系统，我们的HIS必须要达到在与不配的医疗保险系统相配合，但我们不能因为应用了不同的医疗服务而变更HIS中的相关逻辑，那么我们应该怎么办呢？
答案是采用基于接口驱动的思想，我们定义一个HIS医疗保险接口组件(HIS.Medicare.Interface)，HIS系统中使用医疗保险业务的地方切调用这个接口的方法或者服务，而我们在不同的城市实施HIS的过程中，开发出各城市的医疗保险实现组件，比如HIS.Medicare.Lanzhou、HIS.Medicare.BaoTou,我们也可以弄一个空的实现HIS.Medicare.Default，即不使用医疗保险的情况，那么整个结构就如下所示：
HIS系统中的HIS.Medicare.Interface消费者对一切保险业务的处理都是调用HIS.Medicare.Interface包中的业务定义组件，不关心系统运行时倒低采用那一个实现，或者没有实现或者只有一个默认的实现HIS.Mecicare.Default,或许真实运行环境的这具体实现还没有开发，实能在项目中需要才去开发，那么消费者与接口的实现是如何建立联系的呢？
实现的后期绑定
消费者与具体的实现如何建设关系呢，方法有很多种，最常见的莫过于使用抽像工厂模式，也可以使用IOC容器进行解耦，具体如何说呢，我下面示例说明。
比如我们在HIS.Medicare.Interface定义了一个接口IMedicareProvider
1 public interface IMedicareProvider
2 {
3 IMedicareDrugSelect CreateMedicareDrugSelect();
4
5 IMedicareItemInfoSelect CreateMedicareItemInfoSelect();
6
7 IMedicareServiceSelect CreateMedicareServiceSelect();
8 }
而我们在HIS.Medicare.Lanzhou、HIS.Medicare.BaoTou和HIS.Medicare.Default中都实现了这个类，那么我们刚可以在HIS.Medicare.Interface组件中增加如下代码：
1 public static class MedicareProviderHelper
2 {
3 static readonly string ConfigKey = "HIS.MedicareProvider";
4 public static IMedicareProvider MedicareProvider
5 {
6 get
7 {
8 return ContextHelper.GetContext().Container.GetComponentInstance(ConfigKey) as IMedicareProvider;
9 }
10 }
11 }
并且需要在系统配置文件的IOC配置信息中增加如下内容：
1 <object name="HIS.MedicareProvider" assembly="HIS.Medicare.Default" type="HIS.Medicare.Default.MedicareProvider" LifestyleType="Thread" />
上面我处理我使用了AgileEAS.NET平台中的IOC组件，有关IOC的介绍请参考AgileEAS.NET平台之对象控制反转一文。这样处理以后，我们在任何使用IMedicareProvider
接口的地方直接采用MedicareProviderHelper.IMedicareProvider 的方式消费IMedicareProvider
对象。
结束语
事实说明，基于接口开发在某些应用场景能很好的分离服务对象与消费者对象之间的依赖，在软件开发过程中不失为一种非常有效的手段，如果运用的合理，将起到事半功陪的效果，但是，基于接口开发也不是万能的，并不解决问题的唯一银弹，就比如我们传统的文件，架构或者模式的设计一切基于应用为先的原则，即怎么样的业务即采用怎么样的架构技术，不如一味的强求与照搬。合理就好。
| 
