关于接口的设计

  这些天我们正在准备重新规划商户的接口，同事们出了一版设计，但是遭到了我们老大的否定，但是我本身也是比较赞同同事的设计的。矛盾点是在这里：
  我认为，我们作为提供基础数据服务的部门，因为我们基本是最上游系统，所以我认为我们这边应该尽量少的包含业务，尽量使我们的接口更好的通用化，至于下游系统怎么使用我们的数据做它自己的业务，我觉得我们并不太需要去关心。这里我们只拿一个接口我说明，Vender getVender(String code, int type)
比如说type有两种，1代表供应商、2代表联营商，按照我上面所说的理由接口设计出来应该是这样的。
  我们老大认为，作为服务的提供方（server）首先应该站在调用方（client）去考虑，绝大多数的下游系统只是存储一个code信息，他自己一般是知道自己是什么类型的商户，所以他如果使用这个接口就必须传一个1或者2，这个对于客户端来说就不是很友好。这样这个判断类型的逻辑就分散到了各个调用

端，如果以后有了任何的业务变化，比如说判断什么类型的逻辑不是根据这个type了，需要多个if判断才能确定，而这个时候作为服务端的我们如何去推动调用端去改动就太困难了，尤其是身在一个大公司内。到这里我们可以去考虑一个问题，这段逻辑是不是属于我们服务端本身？？其实我们略加思考就可以考虑到，这段逻辑其实是属于服务端本身的，发放到下游确实有些不合适。所以我们重新规划了我们接口的设计:Supplier getSupplier(String code); Associates getAssociates(String code);
  在这里我们多少几句，其实每一个原则都是辩证来看的，多个原则在一起必然会有矛盾，就比如上面，那是不是我们提供出去的接口都要个性化呢？当然不是，如果所有的都个性化，那我们的接口就会爆炸。我们一定要思考，这个接口的个性化是不是符合我们大的业务框架？站在对方的角度思考下。
  如果人生没有了思考，那我们比咸鱼差不了多少。