读后感：分析依赖注入、服务容器的产生

名词：
依赖注入：依赖Dependency 注入Injection 简称DI
控制反转：反转Inversion of Control 简称IoC
容器：Container
在 Laravel 5 中，IoC 容器改名为服务容器，IoC 容器和服务容器指代同一个东西。

原文地址：Laravel 服务容器实例教程 —— 深入理解控制反转（IoC）和依赖注入（DI）https://laravelacademy.org/post/769.html

该篇讲述了如何更高效更合理制造一批超级机器人 superman

以下为个人的理解，尽可能以最简洁的文字写下来，由于是初学，有认知错误请谅解。

假设我们对生产机器人毫无经验

起初现有以下三种技能，每种技能都有不同配置，和手机一样不同的cpu核数内存硬盘大小
蛮力 class:Force{ $force力量值 }
飞行 class:Flight{ $speed速度 $holdtime持续飞行时间 }
射击 class:Shot { $atk伤害值 $range射击距离 $limit同时多少发 }

最初模式

在这里插入图片描述
一个机器人就生产出来了,如果修改技能个数，修改配置，需修改superman类

工厂的诞生

建立一个专门实例技能模块的工厂类，superman只需给工厂需要生产什么技能，什么配置的报表，委托工厂类来实例化技能类。
我们只需要给工厂需要的报表

$arr = [ 
Force =>[101],
Flight =>[ 20m/s,1.5h ]
]

class superman 
{
	protected $modules; //技能
	pub func __construct($arr)
	{
		foreach($arr as $modulename=>$param)
		{
			/**Force=>[ 101 ]*/
			$module =（new factory)->makeModule ($modulename,$param);
			$this->modules[] = $module;
		}	
	}
}

class factory{
	makeModule(){
		//为了不让与技能无关的类被实例化,须预先记录可用的技能类
		switch
		case 'Force'
			return new Force(..)
		case 'Flight'
			return new Flight
		...
	}
}

改革一
在这里插入图片描述
第一代生产线生产效率大大提高。

解除依赖 -

1，superman类对工厂类的依赖（superman的实现取决于工厂的具体实现）。
2，工厂类对技能类的依赖（技能种类的增加；实例化方式改变；实例化的复杂性增加），工厂要对每个技能类了如指掌，每次修改实在是头疼的事情。

我们需要改变生产模式，寻求降低或者解除耦合度。
解除工厂对技能类实现的依赖生产脚本的诞生
首先我不需了解每个技能类如何实例化，由技能类提供自身的实例脚本，打包成一键安装的.exe，我只要鼠标轻轻一点，所有安装自动完成。所以不管组件是中国或者外国哪家公司提供的，可以随时替换更高科技的组件。我们的工厂不负责科技的研发，具体的生产线，只提供各个组件的调度。

'Force.exe'=>function(){ 脚本 }

在这里插入图片描述
解除超人类与工厂的依赖
由超人类调用工厂，变成外部调用

契约的诞生
矛盾：返回的技能实例能不能正常使用呢？
解决：提供契约

interface moduleInterface{
//接口规范
}
class Force implements moduleInterface{
//实现接口
}

在这里插入图片描述

超级工厂- 容器

矛盾：实际我们的事业是维护世界和平，不只是做个机器人生产商，还要宇宙飞船，空间站，火箭。。一整套体系。
解决：和机器人模块一样，机器人也由外部提供，不管是中国还是外国的哪家公司生产的。
在这里插入图片描述
到这里，我们由只生产机器人，变成可以完成登月计划的整体框架。
机器人、火箭、卫星、宇宙飞船类似laravel的路由、视图、模型组件，而机器人的芯片force.exe\flight.exe\shot.exe类似单个组件的服务。
这些组件及组件的服务，由容器调度。

所有组件和服务在容器启动时都已经提前注册到容器中。由于依赖注入去了耦合；由于契约，组件可以替换服务。

我们在应用中只需要一行代码
$app->make(’ superman’,[‘force’,‘flight’]);

end;