接口的设计

这是刚才和一个朋友的聊天记录，希望对大家有帮助：
佘士东 08:41:47
我设计一个接口，其中有些方法很类似，比如取得某个工作对象，有可能需要获得多个，也有可能获得其中一个，参数为工作对象的名字、名字列表。
我是用窄接口还是宽接口好，是用一个最大功能的方法还是多个重载方法好？
比如：
IService
public Worker  getWorker(String name);
public Vector<Worker> getWorkers(final Vector<String> names);
我是在接口约束这两个方法还是只约束最大的那个，使所有的方法都适配为后面这个最大方法，而在接口中去掉第一个方法
杨中科 08:51:57
我认为还是多个重载方法好，主要是考虑方便别人使用
 
杨中科 08:52:31
顺便说一句：为什么参数和返回值要用Vector？用List接口不更好吗？
 
佘士东 08:53:55
如果适用者很有限，大概只有5个左右，实际上使用者也是提供适配功能，比如使用cs结构，web方式，wap方式，sms方式获得接口服务的适配模块
佘士东 08:55:04
我的想法是使用Vector它是异步安全的，服务可能是多线程实现的，所以使用Vector返回，不知道有没有这个必要，有没有这个作用
杨中科 08:55:12
你说的是什么意思，不太明白。你说getworker方法不是所有实现类都能实现？
 
佘士东 08:56:35
其实这个接口是夹在实现和使用这中间的，使用者实现不同类型服务的适配，实现根据项目不同所要求的业务实现不一样，实际上这个接口是约束实现要多
佘士东 08:58:08
如果接口方法太多，我怕如果变更会不会陷入变更里面，因为重载多了，其中很多有重复，比如参数列表，如果需要加上用户验证，那就都要加，这样所有实现都要改动一批
杨中科 08:59:41
“我的想法是使用Vector它是异步安全的，服务可能是多线程实现的，所以使用Vector返回，不知道有没有这个必要，有没有这个作用 ”，你可以将传进来的List参数用Collections类中的syn****List方法将List搞成异步安全的，返回的时候你也可以返回Vector类型的，但是返回值要生成List类型
 
杨中科 09:00:14
要考虑二次开发人员的易用性，大部分人还是倾向于使用List、ArrayList这样的东西的
 
杨中科 09:01:50
“如果接口方法太多，我怕如果变更会不会陷入变更里面，因为重载多了，其中很多有重复，比如参数列表，如果需要加上用户验证，那就都要加，这样所有实现都要改动一批 ”，还是那句话，不要陷入实现的漩涡中，你的接口是声明服务用的，不要管实现，怎么实现是实现类的事情，站在二次开发人员的角度来看你必须同时提供getworker和getworkers两个方法
 
佘士东 09:01:49
原来如此，就是说实际上还是Vector，只不过返回值使用List接口，但是如果他直接转换成ArrayList使用会不会丢掉原来异步安全特性？因为返回值毕竟只是一个引用，可能其它地方也在用同一个引用
杨中科 09:02:30
不可能转换为ArrayList的，否则运行的时候会抛ClassCastException
 
佘士东 09:02:46
但是，二次开发实际上是开发实现类，而不是服务调用类
杨中科 09:03:24
哦，也就是二次开发实际上是写一个实现了你定义的接口的插件？？？
 
佘士东 09:03:47
对，就是这个意思
杨中科 09:04:57
那也最好提供这两个接口，这样你使用这些插件的时候也方便，你可以写一个抽象类来实现默认的getworker方法，在getworker中调用getworkers方法，这样二次开发人员一般只要实现getworkers方法就可以了
 
佘士东 09:04:57
但是这个插件是惟一的，使用一个Factory获得实现
佘士东 09:05:57
哈哈，豁然开朗，宽接口，加上适配抽象父类，就搞定了
杨中科 09:06:26
接口方法是越多用起来越方便
 
佘士东 09:07:10
我只是怕在产生变更的时候，对应的实现也要改动很多，毕竟框架才是初期
杨中科 09:08:29
“对应的实现也要改动很多”，那就看你抽象类的实现水平的，定义接口的时候不要去想实现，只要想接口定义那些方法才够用就可以，实现和接口不能混
 
杨中科 09:09:00
你可以用各种设计模式来保证不会发生“产生变更的时候，对应的实现也要改动很多”
 
杨中科 09:09:11
但是接口就是接口