那些项目中的接口

一个糟糕的的程序接口的设计不仅仅是对接口调用者的摧残,更是对整个系统估值的贬低以及对设计者的能力的贬低。

下午工作的时候,发现在现在的项目,很对接口设计都令人抓狂,在一些地方不仅仅是设计的不好,而是似乎没有经过设计。比如,在一个接口中,明明是只需要一个Device ID (int)列表就能达到目的,却要求传入一个完全的Device列表,调用者不得不构建一个个的Device对象,如果构建这些Device对象是通过web service的方式获取的话,那么会在性能上照成严重的拖累。

软件设计的最少知识原则(PLK)也是KISS原则(Keep It Simple and Stupid)的一种体现,它们都希望使用你设计的接口或者界面的用户,只希望通过最少的操作就能达到他们的目标。就我个人而言,是非常推崇这种设计的,正如那句广告,简约而不简单。

当然,所需要关注的不仅仅是PLK,比如单一职责原则。系统里有很多类似createAndRetrieveXX的方法,可能是我没有足够的背景,但是从一个调用者的角度上,create就create,retrieve就retrieve,为什么要把这两者混在一起?也许有人也会想到JDK  current 里面的compareAndSet 之类 的方法,但是这个方法的目的还是只有一个set,仍然是单一的职责。

另外很多问题也非常值得关注,比如代码的复用,同样的代码块,一样的方法,甚至方法群体在很多地方出现,难道这些就不应该被refactoring么。软件开发中,都不敢冒风险就重构原有的代码,久而久之,代码越来越臃肿,维护性也越来越差,bug出现几率也变得高了起来。