dependency-injection - 工厂模式和依赖注入(inject)的Demeter定律

我有一个关于依赖注入的问题。

说我想创建一堂课
称之为WebGetTask

WebGetTask将需要对HttpService的依赖

错误代码1
码:

private HttpService  httpService;
...
List<WebGetTask> list = new ArrayList<WebGetTask>();
for(...)
{
   list.add(new WebGetTask(httpService));
}
...

好。我知道这很不好，因为注入了httpService，但从未使用过，除了在新的WebGetTask上创建

好
错误代码2
码:

private WebGetTaskFactory webGetTaskFactory;
...
List<WebGetTask> list = new ArrayList<WebGetTask>();
for(...)
{
    list.add(webGetTaskFactory.newTask());
}
...

我认为这更好，因为我们使用工厂
但...
但..

从我站立的地方
我理解了
在WebGetTaskFactory中
我们仍然在注入HttpService，除了创建新的WebGetTask的唯一目的之外，什么都不做

所以
回顾
我的问题是
我如何设计一个工厂类(WebGetTaskFactory)，当新对象在其构造函数上需要依赖项(HttpService)而不简单注入并传递依赖项(HttpService)时创建新对象(WebGetTask)？
或者更确切地说，这是这样做的方式吗？如果是这样，那一切都很好，如果不好，那么请指导我如何正确使用DI和工厂模式。
谢谢。

最佳答案

我将假设您显示的代码是DownloadManager类的一部分，并且您通过构造函数注入了依赖项。在这种情况下，我希望将所有内容粘合在一起的启动代码看起来像这样:

IHttpService httpService = new HttpService();
IWebGetTaskFactory webGetTaskFactory = new WebGetTaskFactory(httpService);
IDownloadManager downloadManager = new DownloadManager(webGetTaskFactory);

DownloadManager类仅知道IWebGetTaskFactory接口。它不知道IHttpService，因此满足Demeter的法则。

编辑:在重新阅读您的问题之后，您似乎担心除了将其传递给新的WebGetTask之外，您没有在工厂中“使用” HttpService。还行吧。 WebGetTaskFactory和WebGetTask都需要一个HttpService实例来完成其工作。这并不违反Demeter法则。