最近刚好在做一个老系统的技术类改造,改造过程带来不小的麻烦。
是什么因素导致改造的复杂度上升呢?我姑且定义为“通用型接口”。
通用型接口定义:在接口定义中使用了一些可变参数做了接口契约参数。比如使
用了长度可变参数列表;使用了Map传递参数等。。。
老系统在做设计的时候为了使模型更具通用性,对业务中的可变部分进行了特殊
的封装,名曰:“扩展字段”(一个MAP)。实现上因人而异,就不多讲了。
对于这种设计,我认为没有错,现在人人都在讲平台,要做成平台,必须屏蔽和
包容一些可变因素。
接口的通用性也是有代价的,不合理的使用,也许会带来较高的维护成本。作
为接口的使用方,怎么样处理来屏蔽后续维护成本剧增的风险呢?
个人认为可以考虑一下两种方式:
1.把“通用型接口”变为“显式接口”。类数量也许会些许增加,但是后续维
护会更清晰;如果能对“显示接口”定义时,提炼出更抽象的模型,比如领域会不会
更好?
例子1.
比如有接口:
void sendMessage(int messageType,Object[] datas)
此接口较为通用,但是没有必要的参数检查,且datas变量自定义性很强。如果
让这样的接口分散太多,可想后续软件和可读性和维护性会变高。
如果我使用的时候把接口包装为:
void sendPaySuccessMessage(String customerId,String orderId,String otherMesg)
此接口用于支付成功时使用,传入的必要的参数,参数会做检查,然后调用sendMessage接口。
2.把“可变部分”维护起来。可变部分给我们带来的困扰是什么呢:我想主要
是“看完代码我也不知道业务为什么需要这样处理”,很多历史原因造就了这类问
题。前一个人写的代码有当时的历史原因,后续人维护的时候已经不知道上下文,所
以变得难于读,难于维护,易于犯错。
总的说来,“通用性”会换来一些维护成本,怎么样屏蔽通用性带来的问题,可
能仁者见仁,智者见智。但是软件的可读性和可维护性也是我们需要考虑的一个方
面。
转载于:https://blog.51cto.com/memoryless/901704