依赖注入容器理解
耦合
一个好的代码结构设计一定是松耦合的，这也是很多通用设计模式的宗旨，就是把分散在各处的同一个功能的代码汇聚到一起，形成一个模块，然后在不同模块之间通过一些细小的、明确的渠道进行沟通。
在实践中，不同功能和模块之间的互相依赖是不可避免的，而如何处理好这些依赖之间的关系则是代码结构能否变得美好的关键。
<?php
class User
{
public function register($user)
{
// 注册操作
...
// 发送确认邮件
$notify = new Notify();
$notify->sendEmail('register', $user);
}
}
class Notify
{
public function sendEmail($type, $data)
{
switch $type {
case 'register':
// 发送注册确认邮件
$email = new Email($type);
$email->send($data);
...
}
}
}
class Email
{
public function send($data)
{
// 发送邮件
}
}
上述代码中，三个类之间逐层依赖，三个类实例化的顺序是 User -> Notify -> Email
也就是说我先实例化User类，可能执行了一些代码之后再去实例化我需要的其他类，比如Notify，以此类推。
这种依赖会让我们不得不为了得到需要的依赖而去做的一些准备工作，有时候可能一个new操作还不够。而这部分工作就是所说的耦合，他会让一个独立功能的类不得不去关心一些和自己的主体功能没什么关系的操作。
解除一个类对其他类的依赖
要解决这个问题也很简单，我可以先实例化好Email类，然后再实例化Notify，然后把Email对象作为参数传给Notify，最后实例化User类，然后把Notify传进去。这就是所谓的依赖注入，可以看到这个过程中类实例化的顺序完全反过来了，先实例化被依赖的对象，而不是先实例化最终需要的对象，这是控制反转。
代码如下：
<?php $email = new Email(); $notify = new Notify($email); $user = new User($notify);
可以通过构造函数来注入需要的依赖，也可以用一些其他的方法。
用容器托管依赖
那又有新的问题，例子中只有三个类还好，那如果这个User类依赖Notify来发邮件，依赖Model来存数据库，依赖redis来缓存，这样固然把依赖关系转移到了类的外部，但还是会导致我只想实例化一下User的时候，却要手动做很多的准备工作，会让代码混乱。所以这个时候需要一个容器。而这个容器的作用就是替我来管理这些依赖。
<?php
// 容器
class Container implements ArrayAccess
{
protected $values = [];
public function offsetGet($offset)
{
return $this->values[$offset]($this);
}
public function offsetSet($offset, $value)
{
$this->values[$offset] = $value;
}
}
内容版权声明：除非注明，否则皆为本站原创文章。