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

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

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

原文地址:Laravel 服务容器实例教程 —— 深入理解控制反转(IoC)和依赖注入(DI)

该篇讲述了如何更高效更合理制造一批超级机器人 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;