这种设计模式是否有一个名称(让自己进入自己的依赖项之一)，这种技术的陷阱是什么?

我不盲目地遵循设计模式(我们真的只需要理解对象通信IMO)，但我也不想忽视它们。

是否有一个设计模式的名称(类似于这里使用的委托模式或可能是一些双重调度策略模式的东西)，但不是重写每个方法和委托，您只需将引用($this)传递给自己到依赖项中?这是程序员工具箱中一个合理的解决方案吗?

需要实际的例子吗?确定……继续…

---

考虑您正在使用DI容器，并且可能有一些像这样的控制器(MVC)方法:

图1:

// Phew! Four dependencies injected here:
public function index(QueryManagerInterface $queryManager, BlogQueryInterface $blogQuery, RenderQueryPDFInterface $queryPDFRenderer, RequestInterface $request) {
    // Do some "managing" of a query, then render it into a PDF
    $queryManager->setQuery($query);
    $queryManager->addInput($request->input());
    $queryPDFRenderer->setQuery($query);
    $output = $queryPDFRenderer->render();
    return $output;
}

现在假设你的Controller方法是这样的:

图2:

// Nice! Just two dependencies!
public function index(BlogQueryInterface $blogQuery, RequestInterface $request) {
    $blogQuery->getQueryManager()->addInput($request->input());
    $output = $blogQuery->getPDFRenderer()->render();
    return $output;
}

我是怎么做到的?所有这些类中的代码都是相同的，除了我更新了$blogQuery:

类

Class BlogQuery Implements BlogQueryInterface, QueryManageableInterface, PDFRenderableInterface {
   public function __construct(QueryManagerInterface $manager, $PDFRendererInterface $pdfRenderer){
      // Here I pass a reference of this own class into its dependencies
      $this->manager = $manager->setQuery($this);
      $this->pdfRenderer = $pdfRenderer->setQuery($this);
   }
   public function getQueryManager() { return $this->manager; }
   public function getPDFrenderer() { return $this->pdfRenderer; }
   ...
}

图2的优点是:

• 减少对控制器方法的依赖
• 更少的代码行
• 组合优于继承(更松散耦合?)。
不需要像使用委托模式那样"输入一堆重复的方法"。
• 更容易理解。只注入BlogQuery和Request似乎捕获了主要上下文。(主观)

---

我在图2中使用了什么模式?这种方法的缺点是什么?这种方法被认为是良好的面向对象实践吗?