客户代码如下：class EventSourceExample{ public void example(Event event, Handler newHandler){ oldHandler = eventSource.installHandler(event, newHandler); } private EventSource eventSource; private Handler oldHandler; }

怎样设计合适的接口(3)

这样，我们给调用者提供了一个更加安全的接口，并且不再需要他们解决线程的问题。从而降低了风险和代码量，将类设计的职责全部给了类设计者而不是推给用户，即使有代理对象的出现也不会影响到正确性。

一个Combined Method可以是许多Query的集合，许多Command的集合，或者两者兼有。这样，它可能补充Command、Query方法，也可能与之相抵触。当冲突发生的时候，优先选择Combined Method会产生一个不同的正确性和适用性。

在另一个例子中，我们考虑获得资源的情况。假设，在下面的接口中，方法acquire在资源可用前阻塞：interface Resource{ boolean isAcquired(); void acquire(); void release(); }

类似于下面的代码会在一个线程系统中推荐使用：class ResourceExample{ public void example(){ boolean acquired = false; synchronized(resource){ if(!resource.isAcquired()) resource.acquire(); else acquired = true; } if(!acquired) ... } private Resource resource; }

然而，即使我们放弃可读性和易用性，这样的设计也不是一个Command-Query分离的设计。如果引入了代理，它就会失败：

class ActualResource implements Resource {...} class ResourceProxy implements Resource {...}

如果用户既可以通过ActualResource来完成工作，也可以通过ResourceProxy来完成工作，而且，ActualResource和ResourceProxy都没有处理同步，则synchronized块可能会失败。因为，既然我们可以通过代理对象ResourceProxy来完成工作，那么，调用者的synchronized块，同步的就是代理对象ResourceProxy而不是最终的目标对象ActualResource。

一个Combined Method解决了这个问题，它使并发和间接性更加透明。

interface Resource{

boolean tryAcquire();

}

下面的代码清晰、简单并且正确：class ResourceExample{ public void example(){ if(!resource.tryAcquire()) ... } private Resource resource; }

Combined Method带来的一个结果是使一些测试和基于断言的程序设计变得十分笨拙，然而，它适合解决线程和分布问题。

实际应用中，接口应该单一化还是复合化，要视具体情况而定。

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!