这里的联合接口指的是，用两个或者多个简单接口联合使用就很容易做的事情，非要定义成一个接口来一次做完。这里先写两个例子。
例子1，有两个接口，exist判断一个文件是否存在，delete删除一个文件。开发人员希望先判断一个文件是否存在，如果存在就删掉，可以用下面的代码来做
if (exist(f)==true){
delete(f);
}
此时团队当中可能有人提出新增一个联合接口，比如说if_exist_then_delete。
例子2，有一个接口，replace将字符串中部分内容进行替换。开发人员希望连续替换，先把aa替换成bb，再把99替换成00，可以用下面的代码来做
replace(str,"aa","bb");
replace(str,"99","00")；
此时团队当中可能有人提出新增一个联合接口，比如说replace_and_replace。
单个员工自己开发的模块当中，将常见的代码组合，合并成一个内部使用的函数，避免某个代码片段重复出现，提高代码整洁度，这是非常正常的事情，但是如果再两个模块之间的接口处也出现这种联合接口，那就是重要的质量问题，需要及时制止，一旦发现需要立即改正。
含义明确，简单直接的接口，从某些场景看可能稍微差点意思，但是它更容易应对大多数场景。好的接口设计应该是一组工具，单个看，每个都很简单，组合起来使用，又能做很多事情，可以支持很多场景。比如说电工手里面的工具箱，各种型号的扳手，螺丝，锤子，锯片。
联合接口本质上就是把复杂的使用接口的逻辑放在了接口定义中，随着时间推移，这样的接口既不好理解，也不好维护。一旦出现当时没有想到的场景，引发了故障，接口的实现者和使用者就会大大扯皮，互相指责对方对接口的理解有误。
从项目管理的角度上来讲，复杂的组合接口，并不是接口的实现者者闲着无聊，自作自受，更多是接口的使用者，出于自己少写代码，强势的逼迫出来的。这种工作风气也要制止。
提出新加联合接口的员工的理由一般不会是直白的说自己想少些几行代码，更多的是以效率为由，新接口可以减少调用次数，可以方便对方优化效率等等。效率优化是一个非常大的领域，但是不到万不得已，没有必要采用联合接口的方式来提高效率。
