工厂模式和依赖注入的 Demeter 法则

Question

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

说我想创建一个类 调用它，WebGetTask

WebGetTask 需要依赖于 HttpService

错误代码 1 代码：

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

好的。 新的 WebGetTask 上创建之外

我知道这很糟糕，因为 httpService 被注入，但它从未使用过，除了在 错误代码 2 代码：

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

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

从我站的地方来看， 我理解了 在 WebGetTaskFactory 中 我们仍然注入一个 HttpService 并且没有对它做任何事情，除了创建一个新的 WebGetTask 的唯一目的，

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

Answer 1

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

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

DownloadManager 类只知道 IWebGetTaskFactory 接口。 它不知道 IHttpService，因此满足 Demeter 定律。

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

Answer 2

好的，在 LoD 下，传递实现对象（构造函数中的“插件”）并没有什么特别的错误。 重要的是，类的接口并没有告诉您太多关于该实现的信息。

如果您的 WebGetTask 接口依赖于 HttpService 的具体实现，那么就违反了 Demeter 法则。

这里的技巧是考虑 WebGetTask 的接口签名。 这个名称本身表明您并没有完全遵循德米特定律（或最少知识原则），因为您定义的类 (1) 被定义为特定于网络，而 (2) 是一个动词名词的。

现在，这两者都不一定是错误的，但如果你愿意的话，它们都是“面向对象的味道”，这表明你可能没有足够客观地思考。

那么让我们尝试“重构”设计。 首先，考虑一个没有与之关联的“web”的 GetTask。 然后，您可以在构建时或稍后构建一个服务对象并将其传入。如果它是 HttpService，那很好，但是您的类的用户不需要任何有关幕后内容的信息。

第二件事，让我们把它变成一个名词。 将其称为 TaskFactory（您的直觉引导您就在那里），它带有一个采用 IOService 的 ctor，我刚刚发明了 IOService，它是由 HttpService 实现的抽象接口。

现在，您已经有了（这是一种 Java/C++ 伪代码，不要对语法细节感到兴奋）：

 class Task { ... }
 class TaskFactory {
    public TaskFactory(IOServer svc){...}
    public Task get(){...}
 }

并且您可以通过编写来使用它

 TaskFactory fac = new TaskFactory(new HttpService());
 Task tsk = fac.get();

现在，我们至少了解 TaskFactory 的内部结构、IO 服务以及就此而言任务。

Answer 3

DI 有两种方式：第一种是构造函数，当只注入一两个对象时很有用，另一种是 setter 方式（实际上需要多少个 setter 就可以）。

如果您想对 DI 使用工厂方法，原则上它与基于构造函数的方法相同。

示例 1，对于构造函数 DI：

list.add( new WebGetTask( httpService ) ) ;

示例 2，对于 setter DI：

WebGetTask webGetTask = new WebGetTask();
webGetTask.setHttpService(httpService);
// set other dependencies
list.add(webGetTask);

当您在创建行为可能不同但具有相同接口（即 LoD）的对象时需要使用一些更大的逻辑时，工厂方法最适合。 假设有一个基于工厂参数动态实现的 DownloadManager 接口。

示例3，创建逻辑封装到工厂方法中：

public static DownloadManager createDownloadManager(HttpService httpService){

    if(null!=httpService){
      WebGetTask webGetTask = new WebGetTask();
      webGetTask.setHttpService(httpService);
      // set other dependencies
      return new DownloadManagerImpl1(webGetTask);
    } else {
      return new DownloadManagerImpl2();
    } // if-else
}