万能接口带来的困扰

我们在写代码时，经常会碰到有多种操作可以采用一个接口来完成的情况。

比如一个员工信息，我在提供查询接口时，支持员工id和员工名称的查询。
这样我们就可以采用一种查询接口

class UserIdDO{
    private long userId;
    private String userName;
}

UserDO queryUserById(UserIdDO userIdDO){
......
}

这样我们只要写一个接口就可以满足两种参数的查询了，看起来这个程序员省了很多事情，少写了一个方法。

但是给后续工作就带来了麻烦。
首先我们要统计员工id和员工名称这量种查询分别要占多少的量，本来我们有现成的统计每个接口访问量的工具，但是由于这个是通过参数来区分的，我们就无法做到了。
其次，当我们不再支持员工名称查询时，我们就需要修改这个接口，这样就会殃及到原先用员工id查询的系统。

评论

2 楼 laodizhuq 2010-03-12  

谢谢您的提议。

其实这个问题是我在维护原有系统时碰到的，
现在的问题是，已经很难修改这类接口了，因为已经有十多个系统中使用这个接口，要修改这类接口起码得花半年的时间，将各个系统都引导到新的接口上面。

这个问题主要是要告诫新程序员在写代码时不要贪图方便，弄出一些很看似通用的接口。

结果等系统做大后，给维护和测试人员带来很大的麻烦。

1 楼 Heis 2010-03-11  

事实上，这种做法在会让别的程序员非常迷惑，写代码不应该只让自己能看明白。方法明写着用Id来查询，结果却是用名字来查询？

必须承认java是很笨的语言，代码应该写则要写，不要求省事。设想一下，如果还需要按其他条件来查询，比如性别，出生日期，你是不是又得改你的类和方法了。增加一个方法是不会对系统造成影响的，但是修改则影响较大。

我的建议是，对于只要一个或两个查询条件，可以以条件为参数来设计方法。当条件多于三个，可以用一个类来对其封装（或者可以考虑直接传sql，但是要考虑sql注入的问题），但是为了防止这个类被滥用，应该将类设为final。方法，类的职责和名字一定要明确，不要试图一个方法多种用途，这样会让别人很迷惑。查询返回的结果和查询的条件应该分为两个类，因为他们的职责不一样。

我建议的一些API形式：
class UserDAO{
UserPO queryByID(String id){}

UserPO queryByIDandName(String id,String name){}

UserPO queryBySQL(String whereStatement){}

UserPO query(UserSearchCriteria criteria){}
}