【发布时间】:2017-11-04 15:51:45
【问题描述】:
我正在寻找最适合我的问题的模式。我有一个定义我的服务类功能的接口
interface NegotiationInterface {
abstract public function resetNegotiation(Negotiation $negotiantion);
}
一个主类实现它
public class NegotiationService implements NegotiationInterface {
public function __construct(…Some Dependencies…)
{
….
}
public function resetNegotiation(Negotiation $negotiantion){
…. //All business logic
}
}
NegotiationService 在 DI 容器(基于 Symfony)下注册,并通过其服务 ID 在整个应用程序中使用。
$negotiationService = $this->container->get(“negotiation_service”);
$negotiationService->resetNegotiation($negotiation);
但是我们的一些客户端(协商包含客户端信息),在调用resetNegotiation之后需要额外的步骤,例如我们常见的业务逻辑+调用webservice。我达到了装饰器模式,但我不确定这是否是使用 DI 时的最佳方法。如果是这样,我将如何与 DI 一起申请。我想根据客户动态加载这些额外的步骤。
【问题讨论】:
-
此时,您的问题有两个很好的答案。如果答案对您有所帮助,请查看它们并接受一个。或者,对答案发表评论以进一步澄清。也就是说,我提供了一个复合模式的例子,我认为它在你的情况下应该很好用..
标签: php oop design-patterns