关于接口设计的理论

（今天写的东西，只是我的个人一些不太成熟的看法。有增减的内容，我会尽量的修改我的理论，呵呵。）

首先，什么是接口呢？接口在对于一个做软件的人来说，其实是无处不在。

软件系统会分成各个模块，各个模块间的联系，我就将之定义为一种接口。例如数据库与前端界面的接口。

各个软件系统之间为了符合客户要求，经常需要有交流，以方便客户操作，避免将类似操作重复进行。例如，ERP系统与CRM之间数据交流的接口。

软件与硬件的连接也有接口，甚至是不少硬件接口。例如，串口通讯的接口等。

假如再细化，对于OO设计来说，各个对象与对外交流的输入输出，也是接口。

正因为接口的广泛性，我考虑了一些通用性的接口设计方法。

对于OO设计来说，一个类的具体设计，怎么设计一个比较好的输入输出接口是一个学问，也是一个被人广泛研究的学问。具体的建议我就不说了，但是有不少可以借用到别的接口设计中。

接口的数据流向：接口有分单向，和双向。通常的接口，都会有输入和输出，我一般会把输出作为一个PUSH操作，输入作为一个PULL操作。

单向数据接口就有一个方向性，一端是数据接收方，一端是数据发送方。我个人认为一个典型的硬件例子就是传感器。一个比较典型的例子是B/S架构。一个主要是数据输入功能，一个是接收数据并处理。（当然，我也知道，现在不少B/S架构的MIS系统，BROWER还完成一个输出显示的功能，有了这个功能，也可以算做是一个双向过程）

双向数据接口经常并不只是一个输入输出的问题，经常还有一个各部分交互的问题。我把数据PUSH给你，然后你告诉我，数据有问题，不可接受，PUSH一个错误状态给我，然后我就修正，再次提交数据。这样的类似过程，在一些复杂接口中经常有，也是一个双向接口的设计难点。

接口应该被封装。也就是说，对外来说，一个模块或者一个部分，只是一个黑盒，黑盒里任何内部处理都给遮盖起来。而对内来说，一切的数据交换都要通过这个输入输出来完成，不应该有特殊。一个好的封装的系统，不应该在内部使用全局的外部的东西。

接口输入输出，这个口应该开的尽可能的小，但是是在满足需求的情况下。输入来说，不要把不需要的东西也放近来，输出的时候，只把必要的需要的输出。

把接口开大可以满足信息输入的要求，但为什么不能把接口搞大些？这里我觉得主要是考虑到一个模块的问题。假如你在一个软件里把两个模块的接口搞的太大，为什么不把两个模块搞成一个呢？假如是在两个软件系统中，把接口搞的过大，也就是说，一个系统有太大的权限，去取得另一个系统的数据，会不会留下安全隐患呢？所以我个人觉得，适用一个够用就好的原则。

先硬后软原则。一般的和硬件有关系的接口，都适用这一原则。硬件的限制，使你不得不在软件上满足硬件的需求。对于软件设计师来说，软件是我的可控部分，而硬件是不可控部分。

接口内容设计。这个部分每个接口不同，我也不多说了。

模块划分。有的部分，可以分模块，有的不必要。划分了模块的好处在于，可以对模块的功能有一个明确的划分，可以分别对每个模块进行处理，进行开发。但缺点是有模块就有接口，但考虑到一个接口的复杂性，整合各个接口构成一个整体的难度。这里有一个平衡点。

我曾经见过一个系统的设计。说的是一个手持的数据采集器软件。它将数据上传，数据下载，数据储存，数据校验，数据采集，数据管理等都说成是一个个的模块。事实是，实际上这个软件也就数百行C语言代码，根本无法细分，数据上传，下载等都是一个语句调用。当然，这个可能是给客户看的，把功能说的悬乎，多卖点钱，但从软件角度，假如都这么细分，软件的接口部分的处理工作量就会远大于各个模块的工作量，而且，你各个模块间也不可能有一个很好的封装。

（今天先说这么多了，还没想到有修改的，以后再说，就当我把现在想到的，在CSDN上留个备份了，呵呵。）