关于接口的问答

问题一：为一个子系统定义接口，然后其它子系统通过接口来进行访问该子系统。这时其它子系统就要“调用”“该系统的接口”，怎么个调用法，通过实现接口中的方法？？？

问题二：比如“后台维护子系统”，它其中有很多“用例类”（类是根据用例抽象来的），每个类都有“增、删、改、查”，这些“增、删、改、查”可不可以抽象出来，抽象成接口，或者基类。

问题三：如果抽象出接口，接口应该怎样定义？？？
  这个接口是对“子系统外”开放，还是对“子系统内“开放？
  第一种方式：接口中定义“增、删、改、查”这些方法，那么方法的实现就是“子系统中的用例类”，子系统外的“子系统”有办 法访问吗？？？这是接口起到什么样的作用？？？这是接口换成基类或是抽象类可能更合适。
   
  第二种方式：接口中定义获取“该子系统用例类”的方法，这时“子系统外”的子系统就可以实现这些“获取”“该 子系统用例类”的方法，进而得到“系统用例类”，进行操作。这样“子系统”就可以被外部使用，这样的接口怎样定义？

问题四：如果抽象出基类或是抽象类

  “把公共的代码抽取出来，减少代码的重复性”这样的抽象类才算合格，有没有实现“增、删、改、查”通用的方法？？？

答：

1. 接口这个词不一定仅仅是空洞的字眼，可能有各种具体的解释，而不一定是特指c#的interface。特别是在设计时期，接口就是指子系统之间的通讯，并没有纠缠于具体的编程语句。比如说传统的api，这里的i就是接口的意思。再比如说通讯协议，也是定义了跨进程的系统的一些接口。当然直接使用编程语言的interface语法定义的类型也是接口。所以说“调用接口”这就要具体问题具体分析，你不去了解人家说的是什么接口，你就不知道到底什么才是“调用接口”。千万不要死抠字眼，而要先去看看字眼在别人心目中（而不是自己心目中）是什么意思。

2. 所谓“增删改查”对于一个真正流行、实用的业务接口设计来说，不超过30%的内容。实际上只有那些没毕业的学生，或者那些一辈子没有脱离了学生习惯的“架构师”，才会从这个角度出发。当然一切信息的改变你都可以说是“怎上改查”，但是这就好像去问“回字有几种写法”而不是去问“回家是什么感觉”一样，纠缠于底层的片段数据的增删改查，而没有直截了当地为前端需求提供接口。比如说我们要邀请所有“快女”出席晚宴，除了说这是给“邀请”动作执行“数据库新增”以外，你还能不能说点真正的设计知识呢？前端只需要访问“邀请”这个接口功能，它才不需要去管后台有没有什么数据库。

回到你的问题，接口建模应该是设计中得到的一个结果，然后用来做演示（即凭此实现一些Mock的暂时实现）跟客户沟通，在原型基础上重新理解用户需求，重新扩充甚至废弃接口设计。从需求出发，了解前端是一单个事务的需求还是一连串需求的方式跟后台通讯，了解通讯时序而设计出接口，而不是从什么底层数据库的增删改查来设计接口。

至于说对于数据库系统的增删改查，数据库系统早已经有接口了，大多用不着你再去以很低级的方式包装什么DAL。除非你需要对数据库系统操作进行很高级的包装。


3. 你的问题有点混沌。我想你一味地从编程出的发，缺乏从测试出发的视角。不论是产品设计，还是开发规划，还是质量管理，等等都是落实在测试上。产品设计者不需要面面俱到，但是它的设计文档要恰好可以落实到测试上即可。开发时，假设一个子系统接口的实现需要3天时间，然后我们留出2天时间富余量，那么应该怎样分配时间？可能需要用半天时间定义好接口以及测试程序，然后用4天时间执行开发工作，并且用4天半时间执行测试工作，即开发过程中随时要用接口来测试和指导开发工作，开发的目的只是为了让测试可以通过，做更多的工作是多余的、有害的。接口起到了让测试可以在开发之前启动的作用。

至于你说的什么“抽象类、基类”什么的，我不回答你。此时不用纠结这些，甚至我们没有必要对接口必须是什么具体形式作出规定。首先应该强调的是工程化开发方法的流程，如果抓住实现这个关键环节，那么就反而可以“放开”那些细枝末节的什么接口形式随便去发挥。


4. 实际上你应该更多从测试角度去考虑。假设你希望，比如说“住院部病人”对象可以放入“病人的报销流程”的所有测试中，同时把“门诊病人”也可以带入所有的病人报销流程的测试中，不应该抛出任何异常，这时候你就自然会考虑抽象问题。如果你为了抽象而抽象、为了复用而复用，比如说仅仅因为出差人员也有报销动作于是把出差人员都当作病人来建模，那么可能张冠李戴而产生严重的测试bug。