接着上篇我们说的配置文件，今天我们来说一下接口。

1、UML图

2、三层架构

3、Sqlhelper

4、配置文件

5、接口

6、设计模式

什么是接口呢？我们可以将接口理解为用于沟通的中介的抽象化。可以将接口理解为我们生活中的“中介”。那么我们为什么要在机房收费系统中加接口呢？机房收费系统中的接口到底起着什么作用呢？看一下下面这段代码，这是我接口的一段代码。

'*********************************************************************************** '作者：高迎 '小组： '说明：接口类 '创建日期：2013.05.25 '版本号：v1.1.0 '*********************************************************************************** Imports Entity Public Interface MainIDAL ''' <summary> ''' 定义一个函数,用来查询Student表中是否有卡号存在 ''' </summary> ''' <param name="thisCardno"></param> ''' <returns>如果不存在提示信息您所上机的卡号不存在，如果存在返回一个表</returns> ''' <remarks></remarks> Function QueryStudent(ByVal thisCardno As StudentEntity) As DataTable ''' <summary> ''' 查到有卡号存在的话往OnRecord表中添加记录 ''' </summary> ''' <param name="thisData"></param> ''' <returns>添加成功返回True,否则返回False</returns> ''' <remarks></remarks> Function InsertOnRecord(ByVal thisData As OnRecordEntity) As Boolean ''' <summary> ''' 同时往OnlineState表中添加记录 ''' </summary> ''' <param name="thisData"></param> ''' <returns>添加成功返回True,否则返回False</returns> ''' <remarks></remarks> Function InsertOnlineState(ByVal thisData As OnlineStateEntity) As Boolean

我们会发现，接口中都是一些方法。其实，细细会发现接口中的这些方法都是“虚方法”。为什么这么说呢？因为接口中的方法（包括方法名、参数、返回类型等）都是从D层照搬过来的，所以是D层依赖接口实现这些方法，所以说接口中的方法都是一些“虚方法”，他们不具有真正的方法内容，真正的方法内容都在D层呢。我们这样做的原因何在呢？我们为什么不直接调用D层的函数呢？为什么要通过接口调用呢？直接调用D层函数看着似乎更方便啊。

其实我们这么做的目的是为了降低耦合度。其实我们做到这里还不是能很好的理解什么"减少耦合度"之类的含义。我们慢慢的会发现我们现在第二遍做的机房收费系统较第一遍做的系统加了很多东西，不再是第一遍为了实现某些功能而实现功能，现在做系统更偏重于设计，更偏重于正规化、规范化，而且本着“全心全意为人民服务的理念”，我们不得不在设计系统时为以后的维护做提前准备。因此，我们由最初的简单实现到后来的用三层架构到后来的加sqlhelper、加接口、加设计模式等等，都是为了降低各个层，各个模块之间的耦合性，为以后的维护或需求变更要进行更改时提供方便。我不知道我这样说你能不能听懂，这是我的理解而已，还有很多的不足之处，很多不正规的地方。我想说的是，暂时的我们要学会用接口，至于接口更深层次的内容我们会随着以后的深入学习更进一步的研究与加深。关于接口的内容我就介绍到这里，希望您能提出宝贵意见，我们共同进步！我们都走在学习的道路上，可能有很多前辈，很多大牛看到我们的博客的时候会提出很多修正意见，非常非常欢迎，我也会随着学习的深入不断的更正、修改我的博客。真诚的谢谢您能提出宝贵意见！