public function __construct() {
$this->$keyboard = new Keyboard();
}
}
这里的Computer类依赖了键盘类。
好，既然我们已经知道了什么是依赖，那么什么是注入呢？
我们改造一下上面的代码：
class Computer {
protected $keyboard;
public function __construct(Keyboard $keyboard) {
$this->$keyboard = $keyboard;
}
}
$computer = new Computer(new Keyboard());
这里的Computer类依赖注入了Keyboard类。
关于依赖注入，我的理解是：
所需要的类通过参数的形式传入的就是依赖注入。
理解了依赖注入，我们可以接着理解 IOC。
IOC
IOC 是什么呢？
中文叫控制反转。啥意思呢？ 这个看明白了 DI 后就能很容易的理解了。
通过 DI 我们可以看到，一个类所需要的依赖类是由我们主动实例化后传入类中的。
控制反转和这个有什么关系呢？
控制反转意思是说将依赖类的控制权交出去，由主动变为被动。
看一段 laravel 代码：
namespace App\Http\Controllers;
use Illuminate\Http\Request;
class SessionController extends Controller
{
public function login(Request $request)
{
//这就是IOC，我们不需要主动传入类了一切由laravel去实现
}
}
看到这你可能有疑问了，这是怎么实现的呢？
这就是靠服务容器了，请往下接着看。
服务容器
看了很多文章，我一致认为服务容器就是一种设计模式。
它的目的就是解耦依赖。
它有点类似于我前面说的《享元模式》。区别在于服务容器解决了所有依赖的实现。
这里我们再从头至尾的看一遍，怎么一步步演化出服务容器。
依然是电脑的例子，我们知道电脑依赖键盘鼠标，可是键盘鼠标也有很多种呀。
先看一个最原始的代码例子：
class Computer {
protected $keyboard;
public function __construct($type = null) {
switch($type) {
case 'common':
$this->keyboard = new CommonKeyboard();
case 'awesome':
$this->keyboard = new AweSomeKeyboard();
default:
$this->keyboard = new Keyboard();
}
}
}
或许你一眼就看出了问题在哪。
如果我们又要增加一种键盘，那我们又得对这个类进行修改。这样下去，这个类会变得庞大且耦合程度过高。
那么我们可以怎么修改呢？
工厂模式
这样我们可以避免直接的修改 Computer 类。
简单工厂
class Factory {
public static function getInstance($type){
switch($type) {
case 'common':
$this->keyboard = new CommonKeyboard();
break;
case 'awesome':
$this->keyboard = new AweSomeKeyboard();
break;
default:
$this->keyboard = new Keyboard();
break;
}
}
}
class Computer {
protected $keyboard;
public function __construct($type == null) {
$this->keyboard = Factory::getInstance($type);
}
}
这样使用简单工厂模式后，我们后续的修改可以不用对 Computer 类进行操作而只要修改工厂类就行了。这就相当于对 Computer 类进行了解耦。