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

王朝other·作者佚名  2006-01-08
窄屏简体版  字體: |||超大  

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

[ 作者: 李炜 添加时间: 2001-9-3 8:06:50 ]

为了解决问题,也需要由类的使用者而不是类的设计者来完成:

class EventSourceExample{

public void example(Event event, Handler newHandler){

synchronized(eventSource){

oldHandler = eventSource.getHandler(event);

eventSource.installHandler(event, newHandler);

}

}

private EventSource eventSource;

private Handler oldHandler;

}

我们假设:目标对象eventSource是远程的,执行每一个方法体的时间和通讯的延迟相比是很短的。在这个例子中,eventSource的方法被调用了两次,并可能在其他的实例中重复多次,因而,开销也是至少两倍。

此外还有一个问题是对外部的synchronized同步块的使用需求。对synchronized块的使用之所以会失败,主要因为我们通过代理对象来完成工作,所以,调用者的synchronized块,同步的是代理对象而不是最终的目标对象,调用者不可能对其行为做太多的保证。

Combined Method必须在分布的环境,或者,线程环境中同时执行。它反映了用户直接的应用,恢复策略和一些笨拙的方法被封装到Combined Method中,并简化了接口,减少了接口中不需要的累赘。Combined Method的效果是支持一种更像事务处理风格的设计。

在一个组合的Command-Query中提供一个单独的Query方法通常是合理的。提供分离的Command方法是不太常见的,因为Combined Method可以完成这一工作,只要调用者简单的忽略返回结果。如果返回一个结果招致一个开销的话,才可能会提供一个单独的Command方法。

回到前一个例子中,如果installHandler method返回上一次安装的句柄,则设计变得更加简单和独立:

interface EventSource{

Handler installHandler(Event event, Handler newHandler);

}

客户代码如下:

class EventSourceExample{

public void example(Event event, Handler newHandler){

oldHandler = eventSource.installHandler(event, newHandler);

}

private EventSource eventSource;

private Handler oldHandler;

}

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

一个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带来的一个结果是使一些测试和基于断言的程序设计变得十分笨拙,然而,它适合解决线程和分布问题。

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

关于作者

李炜:北京杰合伟业软件公司产品技术部经理。1996年四川大学计算机系本科毕业,5年软件开发经验,主要从事基于INTERNET的B/S结构的JAVA开发,专长为数据库、面向对象技术等。

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
 
 
© 2005- 王朝網路 版權所有 導航