最近刚好在做一个老系统的技术类改造，改造过程带来不小的麻烦。

     是什么因素导致改造的复杂度上升呢？我姑且定义为“通用型接口”。

     通用型接口定义：在接口定义中使用了一些可变参数做了接口契约参数。比如使

用了长度可变参数列表；使用了Map传递参数等。。。

     老系统在做设计的时候为了使模型更具通用性，对业务中的可变部分进行了特殊

的封装，名曰：“扩展字段”（一个MAP）。实现上因人而异，就不多讲了。

     对于这种设计，我认为没有错，现在人人都在讲平台，要做成平台，必须屏蔽和

包容一些可变因素。

     

     接口的通用性也是有代价的，不合理的使用，也许会带来较高的维护成本。作

为接口的使用方，怎么样处理来屏蔽后续维护成本剧增的风险呢？

     个人认为可以考虑一下两种方式：

     1.把“通用型接口”变为“显式接口”。类数量也许会些许增加，但是后续维

护会更清晰；如果能对“显示接口”定义时，提炼出更抽象的模型，比如领域会不会

更好？

     例子1.

     比如有接口：

     void sendMessage（int messageType，Object[] datas)

     此接口较为通用，但是没有必要的参数检查，且datas变量自定义性很强。如果

让这样的接口分散太多，可想后续软件和可读性和维护性会变高。

     如果我使用的时候把接口包装为：

     void sendPaySuccessMessage（String customerId，String orderId，String otherMesg）

     此接口用于支付成功时使用，传入的必要的参数，参数会做检查，然后调用sendMessage接口。

     

     2.把“可变部分”维护起来。可变部分给我们带来的困扰是什么呢：我想主要

是“看完代码我也不知道业务为什么需要这样处理”，很多历史原因造就了这类问

题。前一个人写的代码有当时的历史原因，后续人维护的时候已经不知道上下文，所

以变得难于读，难于维护，易于犯错。

 

    总的说来，“通用性”会换来一些维护成本，怎么样屏蔽通用性带来的问题，可

能仁者见仁，智者见智。但是软件的可读性和可维护性也是我们需要考虑的一个方

面。