内容简介:好的设计会提高程序的可复用性和可维护性,也间接的提高了开发人员的生产力。今天,我们就来说一下在很多框架中都使用的依赖注入。要搞清楚什么是依赖注入如何依赖注入,首先我们要明确一些概念。程序要依赖于抽象接口,不要依赖于具体实现。
前言
好的设计会提高程序的可复用性和可维护性,也间接的提高了开发人员的生产力。今天,我们就来说一下在很多框架中都使用的依赖注入。
一些概念
要搞清楚什么是依赖注入如何依赖注入,首先我们要明确一些概念。
DIP (Dependence Inversion Principle) 依赖倒置原则:
程序要依赖于抽象接口,不要依赖于具体实现。
IOC (Inversion of Control) 控制反转:
遵循依赖倒置原则的一种代码设计方案,依赖的创建 (控制) 由主动变为被动 (反转)。
DI (Dependency Injection) 依赖注入:
控制反转的一种具体实现方法。通过参数的方式从外部传入依赖,将依赖的创建由主动变为被动 (实现了控制反转)。
光说理论有点不好理解,我们用代码举个例子。
首先,我们看依赖没有倒置时的一段代码:
class Controller { protected $service; public function __construct() { // 主动创建依赖 $this->service = new Service(12, 13); } } class Service { protected $model; protected $count; public function __construct($param1, $param2) { $this->count = $param1 + $param2; // 主动创建依赖 $this->model = new Model('test_table'); } } class Model { protected $table; public function __construct($table) { $this->table = $table; } } $controller = new Controller;
上述代码的依赖关系是 Controller 依赖 Service,Service 依赖 Model。从控制的角度来看,Controller 主动创建依赖 Service,Service 主动创建依赖 Model。依赖是由需求方内部产生的,需求方需要关心依赖的具体实现。这样的设计使代码耦合性变高,每次底层发生改变(如参数变动),顶层就必须修改代码。
接下来,我们使用依赖注入实现控制反转,使依赖关系倒置:
class Controller { protected $service; // 依赖被动传入。申明要 Service 类的实例 (抽象接口) public function __construct(Service $service) { $this->service = $service; } } class Service { protected $model; protected $count; // 依赖被动传入 public function __construct(Model $model, $param1, $param2) { $this->count = $param1 + $param2; $this->model = $model; } } class Model { protected $table; public function __construct($table) { $this->table = $table; } } $model = new Model('test_table'); $service = new Service($model, 12, 13); $controller = new Controller($service);
将依赖通过参数的方式从外部传入(即依赖注入),控制的角度上依赖的产生从主动创建变为被动注入,依赖关系变为了依赖于抽象接口而不依赖于具体实现。此时的代码得到了解耦,提高了可维护性。
如何依赖注入,自动注入依赖
有了上面的一些理论基础,我们大致了解了依赖注入是什么,能干什么。
不过虽然上面的代码可以进行依赖注入了,但是依赖还是需要手动创建。我们可不可以创建一个工厂类,用来帮我们进行自动依赖注入呢?OK,我们需要一个 IOC 容器。
实现一个简单的 IOC 容器
依赖注入是以构造函数参数的形式传入的,想要自动注入:
- 我们需要知道需求方需要哪些依赖,使用反射来获得
- 只有类的实例会被注入,其它参数不受影响
如何自动进行注入呢?当然是 PHP 自带的反射功能!
注:关于反射是否影响性能,答案是肯定的。但是相比数据库连接、网络请求的时延,反射带来的性能问题在绝大多数情况下并不会成为应用的性能瓶颈。
1.雏形
首先,创建 Container 类,getInstance 方法:
class Container { public static function getInstance($class_name, $params = []) { // 获取反射实例 $reflector = new ReflectionClass($class_name); // 获取反射实例的构造方法 $constructor = $reflector->getConstructor(); // 获取反射实例构造方法的形参 $di_params = []; if ($constructor) { foreach ($constructor->getParameters() as $param) { $class = $param->getClass(); if ($class) { // 如果参数是一个类,创建实例 $di_params[] = new $class->name; } } } $di_params = array_merge($di_params, $params); // 创建实例 return $reflector->newInstanceArgs($di_params); } }
这里我们获取构造方法参数时用到了 ReflectionClass 类,大家可以到官方文档了解一下该类包含的方法和用法,这里就不再赘述。
ok,有了 getInstance 方法,我们可以试一下自动注入依赖了:
class A { public $count = 100; } class B { protected $count = 1; public function __construct(A $a, $count) { $this->count = $a->count + $count; } public function getCount() { return $this->count; } } $b = Container::getInstance(B::class, [10]); var_dump($b->getCount()); // result is 110
2.进阶
虽然上面的代码可以进行自动依赖注入了,但是问题是只能构注入一层。如果 A 类也有依赖怎么办呢?
ok,我们需要修改一下代码:
class Container { public static function getInstance($class_name, $params = []) { // 获取反射实例 $reflector = new ReflectionClass($class_name); // 获取反射实例的构造方法 $constructor = $reflector->getConstructor(); // 获取反射实例构造方法的形参 $di_params = []; if ($constructor) { foreach ($constructor->getParameters() as $param) { $class = $param->getClass(); if ($class) { // 如果参数是一个类,创建实例,并对实例进行依赖注入 $di_params[] = self::getInstance($class->name); } } } $di_params = array_merge($di_params, $params); // 创建实例 return $reflector->newInstanceArgs($di_params); } }
测试一下:
class C { public $count = 20; } class A { public $count = 100; public function __construct(C $c) { $this->count += $c->count; } } class B { protected $count = 1; public function __construct(A $a, $count) { $this->count = $a->count + $count; } public function getCount() { return $this->count; } } $b = Container::getInstance(B::class, [10]); var_dump($b->getCount()); // result is 130
上述代码使用递归完成了多层依赖的注入关系,程序中依赖关系层级一般不会特别深,递归不会造成内存遗漏问题。
3.单例
有些类会贯穿在程序生命周期中被频繁使用,为了在依赖注入中避免不停的产生新的实例,我们需要 IOC 容器支持单例模式,已经是单例的依赖可以直接获取,节省资源。
为 Container 增加单例相关方法:
class Container { protected static $_singleton = []; // 添加一个实例到单例 public static function singleton($instance) { if ( ! is_object($instance)) { throw new InvalidArgumentException("Object need!"); } $class_name = get_class($instance); // singleton not exist, create if ( ! array_key_exists($class_name, self::$_singleton)) { self::$_singleton[$class_name] = $instance; } } // 获取一个单例实例 public static function getSingleton($class_name) { return array_key_exists($class_name, self::$_singleton) ? self::$_singleton[$class_name] : NULL; } // 销毁一个单例实例 public static function unsetSingleton($class_name) { self::$_singleton[$class_name] = NULL; } }
改造 getInstance 方法:
public static function getInstance($class_name, $params = []) { // 获取反射实例 $reflector = new ReflectionClass($class_name); // 获取反射实例的构造方法 $constructor = $reflector->getConstructor(); // 获取反射实例构造方法的形参 $di_params = []; if ($constructor) { foreach ($constructor->getParameters() as $param) { $class = $param->getClass(); if ($class) { // 如果依赖是单例,则直接获取 $singleton = self::getSingleton($class->name); $di_params[] = $singleton ? $singleton : self::getInstance($class->name); } } } $di_params = array_merge($di_params, $params); // 创建实例 return $reflector->newInstanceArgs($di_params); }
4.以依赖注入的方式运行方法
类之间的依赖注入解决了,我们还需要一个以依赖注入的方式运行方法的功能,可以注入任意方法的依赖。这个功能在实现路由分发到控制器方法时很有用。
增加 run 方法
public static function run($class_name, $method, $params = [], $construct_params = []) { if ( ! class_exists($class_name)) { throw new BadMethodCallException("Class $class_name is not found!"); } if ( ! method_exists($class_name, $method)) { throw new BadMethodCallException("undefined method $method in $class_name !"); } // 获取实例 $instance = self::getInstance($class_name, $construct_params); // 获取反射实例 $reflector = new ReflectionClass($class_name); // 获取方法 $reflectorMethod = $reflector->getMethod($method); // 查找方法的参数 $di_params = []; foreach ($reflectorMethod->getParameters() as $param) { $class = $param->getClass(); if ($class) { $singleton = self::getSingleton($class->name); $di_params[] = $singleton ? $singleton : self::getInstance($class->name); } } // 运行方法 return call_user_func_array([$instance, $method], array_merge($di_params, $params)); }
测试:
class A { public $count = 10; } class B { public function getCount(A $a, $count) { return $a->count + $count; } } $result = Container::run(B::class, 'getCount', [10]); var_dump($result); // result is 20
ok,一个简单好用的 IOC 容器完成了,动手试试吧!
完整代码
IOC Container 的完整代码请见 wazsmwazsm/IOCContainer , 原先是在我的框架 wazsmwazsm/WorkerA 中使用,现在已经作为单独的项目,有完善的单元测试,可以使用到生产环境。
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
数据资本时代
Viktor Mayer-Schnberger / 李晓霞、周涛 / 中信出版集团股份有限公司 / 2018-11-1 / CNY 58.00
【编辑推荐】 大数据除了能对我们的生活、工作、思维产生重大变革外,还能够做什么?畅销书《大数据时代》作者舍恩伯格在新书《数据资本时代》中,展示了大数据将如何从根本上改变经济——这并不是因为数据是一种新型石油,而是因为数据是一种新型润滑脂,它将给市场带来巨大能量,给公司带来巨大压力,使金融资本的作用大大削弱。赢家是市场,而并非资本。 这本书在当下国内出版,可以说恰逢其时。时下,中国经济正......一起来看看 《数据资本时代》 这本书的介绍吧!