Php 依赖注入-有没有替代这个非常大的构造函数的方法？

不久，我决定为即将编写的新PHP应用程序使用依赖项注入技术

然而，我不完全确定我是否足够理解它。我的问题是，基类依赖于不同的项，而许多不同的类需要扩展它。例如：

namespace system;

class baseClass
{
 protected $logger;
 protected $filter;
 protected $database;
 protected $session;


 public function __construct(LoggerInterface $logger, filterInterface $filter, databaseInterface $database, sessionInterface $session)
 {
  $this->logger = $logger;
  $this->filter = $filter;
  $this->database = $database;
  $this->session = $session;
 }
}

大多数类都需要logger、filter等来完成它们的工作：例如filter类处理转义/验证，这是我在整个项目中都需要的

我预测的问题是，当（几乎）所有对象都扩展这个基类时，每次我需要实例化一个非常简单的类（当然不是简单到不需要上面描述的项），我就要处理一个可能需要很多参数的构造函数

例如，当创建“car”类的对象时，这对我来说是可以的：

$car = new Car($color,$amountOfWheels);

但在我看来，这似乎相当混乱：

$car = new Car($logger, $filter, $database, $session, $color, $amountOfWheels);

我正在寻找这个问题的解决方案，当然不会违反DI范式。

---

也许某种工厂模式会有所帮助，但为每个小对象创建工厂类对我来说似乎有点过分。

使用DbContext对象怎么样：

$dbContext = new DbContext($logger, $filter, $database, $session);

那么你的“汽车”是：

---

我基本上同意托德的建议。您在这里注入的东西没有直接注入到模型中的位置。重新关联到DB连接，或者Todd所称的上下文。但即便如此，我个人认为这种注入应该是可选的，即使它意味着从外部注册表或连接管理器类获取默认连接/上下文。我的意思是尽可能地减少依赖性是好的，但有时我认为可能会走得太远，只会造成超出需要的复杂性/膨胀。对我来说，这确实是一个不错的选择。尽管我有点担心DbContect对象可能会成为一种“全局”注册表@prodigitalson：这也是一个不错的选择，但有点违反了DI范式。但是如果它只发生在一个基类上，那么它可能没有那么糟糕。

$car = new Car($dbContext, $color, $amountOfWheels);