软件接口设计

软件接口设计

读后记：接口--->对象之间建立连接，指的是进行连接而设计的指定方法；

              java中的interface是为了更好的完成这种连接【多态连接】而定义的一种语法支持；
         相对于抽象类，抽象类一般在多重继承结构下，抽象类去实现接口并具体实现部分方法..

《构建可扩展的Web站点》主要介绍了Web应用程序的概念、体系结构、硬件需求、开发环境的原则及国际化、本地化和Unicode等基本内容，本文是软件接口设计。

AD：51CTO 网+ 第十二期沙龙：大话数据之美_如何用数据驱动用户体验

软件接口设计
Software Interface Design

将软件分层意味着我们需要完成额外的工作——设计层次之间的接口。我们原来拥有的是一大块代码，现在则会有三处不同的代码块（业务逻辑、交互逻辑和标记），它们当中的每一块都需要和下一块交流。但是仔细考虑一下这样做是否的确造成了额外的工作？答案十有八九是否定的：分析一下我们现在仅有的那一层代码，会发现这些附加劳动早就完成了，只有逻辑层和标记层之间的交流还不是很明确，和其他剩余代码混在了一起。

为什么要花心思在分层上呢？不管怎么说，在某种程度上，原来的那种所有代码都粘在一起的程序风格还是可以工作的。然而，有几个决定性的因素，它们将我们引向分层实现，而且随着系统规模逐步扩大，这些因素会一个比一个地变得更为重要。层次分离，让不同的工程师或工程师小组可以同时工作在系统的不同层次，而不用担心无意中影响了他人的工作。除了工作对象变成了不同的物理文件之外，这些小组也不再需要对其他层次有深入了解。标记层的工作人员不必理解数据是如何从数据存储中取出，并且传给模板系统的，他们只需要知道一旦这些数据交付给了他们，应该如何去使用这些数据。

类似的，工作重点在交互层逻辑的工程师也不需要理解在取得一条数据的背后，系统逻辑层是如何运作的，而只需要知道用相应的函数调用就可以了。在这些例子中，工程师们惟一需要关注的元素就是自己所在层次的内容和所在层次与上层和下层的接口。那么，我们一直谈论的接口到底是什么呢？要知道当我们谈的是软件层次之间的接口时，所指的并不是Java中的面向对象概念上的接口。我们所说的接口，描述的是允许一个层次和另一个层次之间交换请求和响应的一组特性。对数据层与系统逻辑层而言，接口包括对原始数据的存储和抽取。对交互逻辑层与系统逻辑层，接口包括对特定类型数据源的修改。接口仅仅定义一个层次如何向另一个层次发出请求，要求它执行一个任务，而不管这个任务如何执行。

我们的应用程序中最为顶端的层次是比较不一样的，因为标记层与表现层之间的接口已经由我们所采用的技术定义好了。标记层到样式表的链接使用的是链接标记符或者@import语句，通过它们获得class和id属性，以及样式表中的命名的标记符序列，根据这些可以应用特定的样式规则。为了保持良好的层次分离，在标记层中应尽量避免直接使用样式属性。本书并不包含前端工程的内容，但前端分层的原因和后端分层的原因是相同的——分离样式层与标记层，才能让不同团队可以独立地工作于项目的不同方面，并且开发人员可以进行层次内部修改，而不用担心影响相邻层次。

交互逻辑层和标记层进行交流的典型方式是模板系统。在PHP和Smarty参考实现中，Smarty为PHP交互逻辑层提供若干功能。我们可以调用 Smarty的方法来将数据导出到模板（继而用于输出），也可以调用Smarty的方法来提供在模板内执行的展现函数，甚至还可以自己直接渲染模板。在某些情况下，我们需要的并不是直接得到模板的输出，然后将输出发送给终端用户。比如在发送电子邮件的时候，我们可以在模板系统中为它创建一个模板，导出所需要的数据和功能，把这个模板渲染到交互逻辑层的一个变量中，然后发送这封邮件。采用这种做法时，要注意到数据与控制不仅是单向流动的，控制在所有层次之间都可以双向传递。

两个逻辑层之间的接口，根据具体实现，很可能是最容易理解的，也是最难以设计的。如果两个层次使用的是同一种语言，接口可能只是一组函数。这时，接口的设计包括决定命名方案（用于函数命名）、调用方案（用于加载正确的库，以使函数可用），以及数据方案（用于将数据向前或向后传输）。所有这些方案都算在系统逻辑层逻辑模型的概要设计中。我喜欢将可能的设计选择画成一个连续的光谱图，称之为网络应用犯傻程度：

OGF <---------- 心智健全----------> 面向对象程序设计

这个光谱往左是单个的巨型函数，往右则接近面向对象程序设计。老式的、单一的Perl系统在光谱中非常靠左，而Zope和Plone的位置在右边。更为有趣的一些模型则沿光谱分布，其中MVC群体集中在中心三分之一处。像Struts和Rails这一类的框架，则分布在右侧靠近Zope的地方（这提醒了你接下来会发生什么）。Flickr在中间稍偏左，它采用类似MVC的方式，但没有使用框架，随着时间的推移和系统的越来越复杂，它也逐渐向右偏移。

你选择定位在光谱上的哪一个位置进行工作，那完全是个人偏好问题。往右走，就以灵活性为代价，获得可维护性。往左走，就丧失可维护性，获得灵活性。偏离中心越远，优化系统就会越困难，但系统架构就会越简单。当前趋势是明确地远离左侧，而中右侧的框架越来越受到欢迎。但始终要牢记，你往一个方向移动，并获得某种好处的同时，也会失去一些别的东西。

堆栈最底部的层次总有定义比较完美的接口，因为它们物理上是分离的——你总不会想用PHP来实现自己的数据库吧？所以这一块的接口定义和层次分离总是以抽象层次的形式发生在应用程序代码内部。业务逻辑层没有必要知道物理上如何连接到数据库集群，但是建立连接的代码需要知道如何连接。分离的数据库与存储层从系统逻辑层获取指令，连接到数据存储，执行指令并返回结果。例如，业务逻辑层可能知道它需要执行一些SQL语句，并知道需要在哪个集群上执行这些语句，它就可以进行如下调用：

$result = db_query('my_cluster', 'SELECT * FROM Frobs;')

接下来就是存储层的责任了，它的代码要连接到正确的服务器，执行命令并返回结果。执行查询的服务器可能发生变化（交换硬件时），可能被复制（也许用于冗余故障转移），可能被记入日志并进行基准测试（参阅第8章中的MySQL小节），或者执行任何我们决定的操作。这个例子中的接口是db_query( )函数和它的伙伴们。对于文件存储层而言，接口中可能包含store_file( )函数，给它传入文件名后，接着就由它来表演魔术了。这个魔术本身怎样和系统逻辑层无关，我们只要执行了需要的调用，就能得到需要的结果。

接口设计在Web应用程序体系结构中扮演着最主要的角色。接口会随着时间而演变，接口变动时，负责不同层次工作的团队必须得进行协商，但是这些更改应该只牵涉到小部分当前开发的内容。在不会无意中破坏其他部分的情况下，我们能在单个层次内做的越多，生产效率就越高，灵活性也越高。