应该如何阻止需要阻止但不是由客户端的服务？

简单的答案就是拥有一个包含stop（）方法的所有常规操作的接口。应该如何阻止需要阻止但不是由客户端的服务？

interface Service { 
    operation(parameters ...); 
    somethingElse(parameters ...); 

    stop(); 
}

停止方法的主要问题是大多数获得服务引用的客户端应该也可能不能停止服务。

另一种选择是简单地定义两个接口，服务和停止的

interface Service { 
    operation(parameters ...); 
    somethingElse(parameters ...); 
} 

interface Stoppable { 
    void stop(); 
}

这种方法的唯一的问题是如果实现由另一服务包裹，然后停止方法被隐藏了。

阻止客户端“停止”服务的原始问题仍然存在，他们只需要首先检查引用是否为Stoppable的实例，然后他们可以“停止”它。

你会如何解决这个问题？

我有一个想法，它优雅地解决了这个问题（对我来说），而没有离开公共站点可用。然而，在我展示它之前，我想要一些想法。

来源

2011-01-20 mP.

我很好奇，看到你的问题的优雅解决方案。 – Falanwe 2011-01-20 10:43:20

-1

使用接口继承：

interface Service { 
    operation(parameters ...); 
    somethingElse(parameters ...); 
} 


interface StoppableService extends Service { 
    void stop(); 
}

的客户端只需要在原服务中获得因为通过适当的工厂方法。任何应该能够停止服务的请求StoppableService。

如果您担心客户端投掷到StoppableService可以调用stop（），那么您需要具体的实现来分离出这个函数。给他们一个具有stop（）的无操作版本的具体实现。您仍然可以让您的工厂向任何应该能够阻止它的人提供stop（）的工作实现。也许当他们向工厂要求实施时，他们可以传递适当的凭据，以便确定他们应该做的事情并给予他们正确的版本。

来源

2011-01-20 13:33:46 GaryF

您需要为最后一段想法提供示例。 – 2011-01-20 14:03:22

如果我明白你的意思，工厂根据某些魔法凭证返回Service或StoppableService。这是因为任何使用该工厂的人都想要一个服务，将凭据引入到这意味着解决方案变得麻烦，因为我们现在必须管理什么凭证足以实现停止。大多数事情应该能够称为可停止的，不关心服务部分，他们只希望在他们想要停止时停止（）它。将不相关的两个接口混合在一起的不好的做法。 – 2011-01-20 22:03:12

-1

你可以做类似

interface Service { 
    operation(parameters ...); 
    somethingElse(parameters ...); 

    <E> E getControlInterface(Class<E> clazz); 
}

然后

Stoppable stoppable = service.getControlInterface(Stoppable.class); 
if (stoppable != null) { 
    stoppable.stop(); 
}

但我认为这是过于复杂，实施Stoppable接口应该是足够的。包装应该知道Stoppable并且实现它。

来源

2011-01-20 14:21:07 pingw33n

应该如何阻止需要阻止但不是由客户端的服务？

回答

相关问题