初识依赖注入

依赖注入，又称为控制反转（Inversion of Control，英文缩写为IoC）是一个重要的面向对象编程的法则来削减计算机程序的耦合问题，也是轻量级的Spring框架的核心。 控制反转一般分为两种类型，依赖注入（Dependency Injection，简称DI）和依赖查找（Dependency Lookup）。依赖注入应用比较广泛。IoC 可以认为是一种全新的设计模式

以上摘自百度百科，概念我们都知道是抽象的，难以理解的，要多在实际应用去慢慢体会。举个例子：

假如让我们组建一支足球队代表国家去参加世界杯，全球有这么多不同的国家，大家都想要参加比赛，那么首先，国家都有一个足球队是不是，所以 国家依赖足球队(团队)，但是团队是由球员组成的是不是，所以团队依赖球员，有了这样的关系，我们就可以建立一些遵循这些关系的类，很简单，核心的三个类不能少，国家（Country），团队（Team），球员（Player），看代码：

class Country {}

class Player {}

class Team {}

这些类目前都是“空”的。让我们想一想， 首先一个 Country 得有个基本属性 name 吧，比如就交 PRC，它依赖一个 Team，

以对象作为参数传递

class Country 
{
    protected $team;
    protected $name;
    
    public function __construct(Team $team, $name = 'PRC')
    {
        $this->team = $team;
        $this->name = $name;
    }
}

这里，我们传递了两个参数给构造函数，第一个参数就是使用了 Type Hinting，你可以称为类型约束或类型提示，来达到依赖注入。第二个参数就是简单的国家名称，默认 PRC，到这里我们国家有了，因为有名字了啊， 依赖一个团队 Team，但是 Team 还是空的，别急，让我们给 Team 加点球员，没有球员打 J8 球，还得是大牌，来定义一个 join 方法：

class Team
{
    protected $players = [];
    
    public function __construct($players = [])
    {
        $this->players = $players;
    }
    
    public function join(Player $player)
    {
        $this->players[] = $player;
    }
    
    public function getPlayers()
    {
        return $this->players;
    } 
}

首先，我们定义了一个 players 数组属性用来存储我们的球员，当我们组建一个团队的时候，我们将自动生成一个 players 球员数组来控制加入团队的球员。在 join 方法中再一次以 Type Hinting 的方式传递一个 Player 实例，只不过这一次实在普通方法里传递参数。最后用一个简单的获取方法 getPlayers 来获取我们加入到团队的球员，不然，这个 Team 类，是不是就只进不出了。接下来，我们要给我们的球员取个名字，要不然都不知道有哪些大牌加入我们的 Team 呢：

class Player 
{
    protected $name;
    
    public function __construct($name)
    {
        $this->name = $name;
    }
}

好像到目前为止，依赖关系比较清晰了呢，但我们还有个小问题，怎样让球员加入指定的国家呢？比如让梅西为我大天朝效力。所以，很显然国家必须有招募球员的能力：

发送消息

class Country
{
    protected $team;
    protected $name;
    
    public function __construct(Team $team, $name = 'PRC')
    {
        $this->team = $team;
        $this->name = $name;
    }
    
    public function recruit(Player $player)
    {
        $this->team->join($player);
    }
}

现在国家就用了招募球员到他们自己的团队里去了，这里我们可以将这个过程称为消息传递，message passing，方法的名称和输入的参数被概念化为消息，看成类与类，类与对象，对象与对象之间的通信。回头再梳理一遍依赖关系，正如前面所说，国家依赖团队，所以我们在 Country 的构造函数里传递了 Team 实例，那么实现这个过程，我们就应该首先创建一个 Team 实例，然后创建一个 Country 实例，并传递 Team 实例给 Country：

$team = new Team;
 
$china = new Country($team);

OK，接下来招募 Players 到 Team 中：

$player1 = new Player('梅西');
$china->recruit($player1);

然后，让我们确认下是不是梅西就到了国家队了：

$team->getPlayers();


Array
(
    [0] => Player Object
        (
            [name:protected] => 梅西
        )
)

至此梅西已经来到国家队为我们征战世界杯了，诶，不对，足球不是一个人的游戏诶，梅西再牛逼没有队友怎么玩，继续招募球员：

$player2 = new Player('C罗');
$player3 = new Player('内马尔');
$player4 = new Player('科比');
$player5 = new Player('詹姆斯');
…………
…………
 
$usa->recruit($player2);
$usa->recruit($player3);
$usa->recruit($player4);
$usa->recruit($player5);


$team->getplayers();

至此，新一届的国家队已经成立，这阵容世界杯妥妥的。

总结:

很简单的依赖注入的小示例，首先我们并没有为了完成这个业务逻辑而创建一个大而全的类，试图将所有的功能放在一个位置，而是分成很多业务逻辑比较单一和清晰的小类，即使这些类是分开的， 他们也能够通过 message passing 或彼此调用方法来通信。是不是感受到松耦合，容易维护的地方了，比如足球队不要了，来个军队要开战了，招募点敢死队是不是很方便？