接口在服务的提供者和使用者之间签订了一个契约，将服务的具体实现封装起来，在保证双方各自独立的情况下，提供了功能调用的稳定性。当软件修改、升级或进行其他变动时，双方都可以各自独立的变化，但是，这个契约不能够变，这是软件稳定性的保证。
“面向接口编程，而不是面向实现编程”2。为了使软件架构更加合理，同时，也为了团队之间的合作，以及后续软件开发工作的顺利展开，软件设计的第一个工作，便是为软件的各个横向和纵向的部分制定调用接口。
特别注意的是，我们在设计基于数据库的应用系统的时候，当两个模块发生交互的需求时，应当避免使用直接在数据库中搬运数据的方法，而应当在程序中调用模块定义的接口方法，否则，对数据库的任何修改，都将带来噩梦般的问题。调用接口方法，而不是直接操纵数据库。
下面来看一个具体的例子：
这是一个BBS的例子。为了清楚的说明问题，让我们把问题尽量简化。现在设这个系统共有两个组成部分：用户登录信息维护和论坛发帖。
我们可以把这个系统划分成两个模块：UserSystem和ArticleSystem。
UserSystem将会包含以下功能：
l 新用户注册
l 修改用户信息
l 用户登录
因此，UserSystem的功能可以用代码表示如下：
public class UserSystem
{
public void CreateNewAccount(Account acount)
public void UpdateAccount(Account acount)
public bool Login(Account acount)
}
而ArticleSystem的功能比较简单，就是发贴，代码可以如下：
public class ArticleSystem
{
public void CreateNewArticle(Article article)
}
因为在发送帖子的时候，需要知道当前发贴的人，会用到UserSystem中的用户信息，因此，UserSystem必须提供这个访问接口，我们在UserSystem中添加一个属性：
public static Account GetCurrentLogAccount{}
这个GetCurrentLogAccount便是UserSystem为ArticleSystem提供的访问接口。ArticleSystem不需要知道GetCurrentLogAccount的具体实现方法，他只需要知道，当他需要使用用户登录信息的时候，调用这个方法就可以了。以后，无论UserSystem进行如何的变化，甚至改变数据库中Account表的设计，只要GetCurrentLogAccount这个调用接口不变，都不会影响ArticleSystem。注意：千万不要在ArticleSystem中直接SelectUserSystem的Account表。
以上的接口，是一个广义上的接口的概念。至于语言层面的接口的妙用，在《设计模式》中，几乎到处都是。
上面所述，是应用系统横向的接口，下面，我们来看系统纵向接口的问题。
关于系统层次的问题，在后面会详细论述，在这里，为了说明问题，我们先做一个简要说明。 
|
本类阅读TOP10