依赖注入、控制反转容器、服务定位器
设计模式 刘宇帅 6年前 阅读量: 1448
在了解依赖注入和服务定位器之前先了解以下两种模式的思想基础:依赖倒置原则和控制反转
依赖倒置原则(Dependence Inversion Principle,DIP)
定义
- 高层次的模块不应该依赖于低层次的模块,两者都应该依赖于抽象接口。
- 抽象接口不应该依赖于具体实现。而具体实现则应该依赖于抽象接口。
问题由来
类A直接依赖于类B,假如要将类A改为依赖类C,则必须修改类A的代码来完成,这种场景下一般A类为业务类,而B、C类为底层模块,假如因此修改了A类代码,会给程序带来不必要的风险。
解决方案
将A类修改为依赖接口D,类B和类C分别实现接口D,类A通过接口D和B、C发生关联,这样会大大降低修改类A的概率
控制反转原则(Inversion of Control,IoC)
DIP是一种思想,而IoC是对DIP的一种实现思路,IoC核心思路就是把A类对B、C类的依赖过程交给第三方来管理。即A给地方要依赖,具体给B还是C、怎么实例化都由第三方决定。
依赖注入(Dependece Injection,DI)
依赖注入是对IoC思路的一种模式,按照Di的模式就可以实现 IoC,符合DIP原则,DI 的核心是把类所依赖的类等的实例化过程放到类的外面实现。例如构造函数注入、属性注入、set函数注入等。
控制反转容器(IoC Container)
按照DI的方式实现了依赖注入,但是对于大型项目,如果每个类都是手动去注入就会让系统变得很复杂。而 Ioc Container 就是一个容器,里面包含了各种类的自动创建、并自动注入依赖单元,这样就减少了很多代码量。
服务定位器(Service Location)
服务定位器也是一个容器,里面有基础服务的实例化方式,而且每个类或服务只会实例化一次,共用实例提高性能,而且支持对每个类或服务的实现方式进行修改。
Laravel里的实现
在 laravel 里对控制反转的应用比较多,像门面(Facade)、服务提供者这些都是。我这里大致看了下路由 action 中对其的应用。
一个简单的 hello 的 action 如下
namespace App\\Http\\Controllers;
use Illuminate\\Http\\Request;
class IndexController extends Controller
{
public function hello(Request $request)
{
echo "hello world!";
}
}
Laravel 里IoC Container 就是 $app (例如 CGI 模式下:Illuminate\Foundation\Application)。上面的controller就是由$app 的 make 函数自动创建的,代码如下
// 类 Illuminate\\Routing\\Route 的源码
public function getController()
{
if (! $this->controller) {
$class = $this->parseControllerCallback()[0];
// 这里的container就是$app,通过 make 函数实例化 controller
$this->controller = $this->container->make(ltrim($class, \'\\\\\'));
}
return $this->controller;
}
而 action 所需要的参数是自动注入的,代码如下
// 类 Illuminate\\Routing\\ControllerDispatcher 的源码
public function dispatch(Route $route, $controller, $method)
{
// 解析函数依赖的参数,往里跟的话依然可以看到 action 参数实例化同样会用到 Ioc 容器
$parameters = $this->resolveClassMethodDependencies(
$route->parametersWithoutNulls(), $controller, $method
);
if (method_exists($controller, \'callAction\')) {
return $controller->callAction($method, $parameters);
}
// 传入解析参数并调用
return $controller->{$method}(...array_values($parameters));
}