1

我有一个我称之为我的类Dispatcher，当它的dispatch()方法运行时，它会实例化请求的控制器。

我AbstractController有一个像这样的构造函数

public function __construct(RequestInterface $request, ResponseInterface $response, ViewFactory $viewFactory, ServiceFactory $serviceFactory)

如您所见，我的控制器有 4 个依赖项。

在我实例化我的那一刻，我Dispatcher将ViewFactoryand注入ServiceFactory到它的构造函数中，然后当我运行该dispatch()方法时，我提供RequestandResponse对象作为参数，然后我可以将所有四个依赖项注入到我的控制器中。

在调用dispatch()方法时提供所有控制器依赖项或在构造函数中提供所有控制器依赖项Dispatcher然后运行dispatch()不带参数的方法会更好，还是总体上有更好的方法？

4

2 回答 2

2

在调用某个方法之前，您有 4 个要注入新控制器实例的依赖项，2 个具有请求/响应生命周期，2 个具有更长的生命周期（进程？）。我会通过创建控制器工厂将控制器的创建与调用分开。

控制器工厂将使用仅接收请求和响应对象作为参数的方法来实例化控制器。工厂会知道两个生命周期较长的依赖项的生命周期，可能共享相同的生命周期。然后，工厂的用户可以自由地在返回的（抽象）控制器上调用他们想要的任何方法。这比您建议的委托模式更灵活。您当然仍然可以使用委托，但是我可能仍然让 Dispatcher 只进行调度并将对象创建留给工厂。

当然，这类问题没有正确答案。这一切都取决于很多因素（要求、代码库的大小、项目等）。希望这会有所帮助。祝你好运！

于 2013-04-20T16:18:24.937 回答
2

一些“废话”

这是我在设计 API 时使用的经验法则：如果你的类有 3 个以上的依赖项，那么它做的太多了。

您在构造函数中传递的依赖项应该是您的实例运行所必需的。就您而言，您在那里有一个控制器。控制器职责如下：

控制器可以向其关联视图发送命令以更改视图对模型的表示。它还可以向模型发送命令以更新模型的状态。   来源：维基百科

控制器不应该负责视图实例的创建或渲染。

关于原来的问题：

我不确定Dispatcher实例的作用是什么，但它们不应该处理创建逻辑本身。您在这里最终得到的是可能的LoD违规和明确的SRP违规的混合。

创建逻辑应该隔离到工厂和构建器。这种方式还可以让您将Dispatcher实例与控制器构造函数的足迹分离。目前，如果您引入了不同的控制器子类，具有不同的依赖项集，您还需要更改Dispatcher实现。

至于“如何制造工厂”，你可以在这里找到一个简化的例子。

于 2013-04-21T07:56:51.053 回答