升级工厂前的准备工作

无规矩不成方圆,随着越来越多的行为出现,我们需要需要定下一些规范。

为了约束每一个行为的规范,需要定义一个行为接口:

interface BehaviorInterface
{
/**
* 行为激活方法
* @param array $values 激活的参数
*/
public function activate(array $values);
}

按照接口规范修改前述的行为类:

class Attack implements BehaviorInterface{
protected $value = 0; public function __construct($value)
{
$this->value = $value;
} public function activate(array $values){}
} class Defend implements BehaviorInterface{
protected $value = 0;
public function __construct($value){}
public function activate(array $values){}
} class Move implements BehaviorInterface{
protected $speed;
public function __construct($speed){}
public function activate(array $values){}
} class Skill1 implements BehaviorInterface{
protected $name = '暴击';
public function __construct(){}
public function activate(array $values){}
} class Skill2 implements BehaviorInterface{
protected $name = '眩晕';
public function __construct(){}
public function activate(array $values){}
}

使用依赖注入升级工厂

  1. 为了解决工厂对行为的依赖,在每一种行为定义好之后就放到工厂中(依赖注入)。
  2. 放到工厂中的行为必须是依照规范定义的。

class BehaviorFactory
{
protected $instances; public function setBehavior($behaviorName, $behavior)
{
if($behavior instanceof BehaviorInterface) {
$this->instances[$behaviorName] = $behavior;
}
} public function getBehavior($behaviorName)
{
return $this->instances[$behaviorName];
}
} $factory = new BehaviorFactory();
$factory->setBehavior('Attack', new Attack(0));
$factory->setBehavior('Defend', new Defend(0));
$factory->setBehavior('Move', new Move(0));
$factory->setBehavior('Skill1', new Skill1());
$factory->setBehavior('Skill2', new Skill2());

对英雄类做一些简单的修改:

class Hero
{
protected $behavior = []; public function __construct($factory, array $behaviors)
{
// 通过工厂提供的方法制造需要的模块
foreach ($behaviors as $behaviorName => $behaviorOptions) {
$behavior = $factory->getBehavior($behaviorName);
$this->behavior[] = $behavior->activate($behaviorOptions);
}
}
} $hero = new Hero($factory, [
'Attack' => [10],
'Defend' => [5],
'Move' => [30],
'Skill1' => [],
]);

至此,我们通过依赖注入,已经彻底地解决了英雄对行为的依赖、英雄对工厂的依赖、工厂对行为的依赖。

但是还有一些不足之处:

  1. 所有的对象,我们都必须手动去实例化;
  2. 这些行为,无论英雄是否需要,都要提前实例化并放到工厂中。

再谈依赖注入

前面的文章中我们已经讲解了如何通过PHP的反射机制来解决依赖注入的问题。这里我们再来深入一下对依赖注入的理解。

什么是依赖注入:

所谓的依赖注入,意思是只要不是在类内部产生的对象依赖(比如在初始化、构造函数中,通过工厂方法或者手动实例化),而是由外部以参数或其他形式注入(传入)的,都属于依赖注入(DI)。

超级工厂-IOC服务容器

接下来将我们的升级工厂,进一步改造为超级工厂。

定义一个简单的容器类,用来存储对象实例化的方式和创建对象:

class Container
{
// 存放抽象类与对象实例化方式关系的数据
protected $binds; // 存放抽象类与已有的对象关系的数据
protected $instances; // 将抽象类与[对象实例化方式|已有的对象]分别存入数组
public function bind($abstract, $concrete)
{
// 如果第二个参数是闭包,则存入 $binds 数组
if ($concrete instanceof Closure) {
$this->binds[$abstract] = $concrete;
}
// 如果第二个参数不是闭包,则为已经实例化的对象,存入 $instances 数组
else {
$this->instances[$abstract] = $concrete;
}
} // 根据对象实例化的方式创建对象并返回
public function make($abstract, $parameters = [])
{
// 如果是已经实例化的对象则直接返回
if (isset($this->instances[$abstract])) {
return $this->instances[$abstract];
} // 将$this(容器)放入参数数组的头部
// [$this, $param1, $param2...]
array_unshift($parameters, $this); // 调用对象实例化的方法(即绑定时传入的闭包函数和当前的参数),得到实例化后的对象并返回
// function($container, $behaviorName) { return new Hero($behavior); }
// function($this, 'skill1') { return new Hero('skill1'); }
return call_user_func_array($this->binds[$abstract], $parameters);
}
}

测试这个容器:

// 创建一个容器
$container = new Container; // 向该容器添加英雄的生产方式(实例化的方式)
$container->bind('hero', function($container, $behaviorName) {
$behavior = $container->make($behaviorName);
return new Hero($behavior);
}); // 向该容器添加行为的生产方式(实例化的方式)
$container->bind('skill1', function($container) {
return new Skill1;
}); // 同上
$container->bind('skill2', function($container) {
return new Skill2;
}); // 开始启动生产
$hero1 = $container->make('hero', ['skill1']);
$hero2 = $container->make('hero', ['skill2']);

在这个容器中,我们通过绑定操作,可以向超级工厂注册很多各种各样的生产脚本(可以是匿名函数、非匿名函数、类的方法),这些脚本在生产操作触发的时候就会被容器调用执行。

通过依赖注入和容器,我们彻底解决了所有对象之间的依赖关系;最重要的是,容器类也没有和英雄、行为之间有任何的依赖。另外也不需要再去手动实例化对象,还实现了按需实例化。

实际上,真正的 IoC 容器更为高级,会根据类的依赖需求,使用PHP的反射(Reflection)机制,自动在注册、绑定的一堆实例中搜寻符合的相关依赖,并自动注入到构造函数参数中去。

深入 Laravel 内核之IOC容器的更多相关文章

  1. 理解PHP 依赖注入|Laravel IoC容器

    看Laravel的IoC容器文档只是介绍实例,但是没有说原理,之前用MVC框架都没有在意这个概念,无意中在phalcon的文档中看到这个详细的介绍,感觉豁然开朗,复制粘贴过来,主要是好久没有写东西了, ...

  2. Ioc容器与laravel服务容器初探

    一.Ioc容器 某天,小J心血来潮,决定建造一艘星舰,这艘星舰要搭载"与众不同最时尚,开火肯定棒"的电磁炮.于是他写了一个星舰类: class ElectromagneticGun ...

  3. laravel核心Ioc容器

    laravel容器和依赖注入 啥是Ioc容器,方便我们实现依赖注入的一种实现,也就是说依赖注入不一定需要控制反转容器,只不过使用容器可能会方便些. laravel通过向容器中绑定接口的具体实现,可实现 ...

  4. 通过中看不中用的代码分析Ioc容器,依赖注入....

    /** * 通过生产拥有超能力的超人实例 来理解IOC容器 */ //超能力模组接口 interface SuperModuleInterface{ public function activate( ...

  5. 【转】Spring学习---Spring IoC容器的核心原理

    [原文] Spring的两个核心概念:IoC和AOP的雏形,Spring的历史变迁和如今的生态帝国. IoC和DI的基本概念 IoC(控制反转,英文含义:Inverse of Control)是Spr ...

  6. Laravel核心之IOC和Facade 架构分析1

    控制反转(Inversion of Control) 缩写为IoC 最常见的方式叫做依赖注入 简单说来,就是一个类把自己的的控制权交给另外一个对象,类间的依赖由这个对象去解决. Laravel 中的使 ...

  7. PHP 在Swoole中使用双IoC容器实现无污染的依赖注入

    简介: 容器(container)技术(可以理解为全局的工厂方法), 已经是现代项目的标配. 基于容器, 可以进一步实现控制反转, 依赖注入. Laravel 的巨大成功就是构建在它非常强大的IoC容 ...

  8. laravel5.8 IoC 容器

    网上 对容器的解释有很多,这里只是记录,搬运! 1.简单理解: 2019-10-10 11:24:09 解析 lavarel 容器 IoC 容器 作用 就是 “解耦” .“依赖注入(DI) IoC 容 ...

  9. Spring学习记录1——IoC容器

    IoC容器 1.1  IoC概述 Ioc(Inverse of Control,控制反转)是Spring容器的内核.对于软件来说,即某一接口具体实现类的选择控制权从调用类中移除,转交给第三方决定,即由 ...

随机推荐

  1. vue 第三方图标库

    "font-awesome": "^4.7.0", "dependencies": { "axios": "^ ...

  2. 基于war的Spring Boot工程

    一.简介 前面创建的Spring Boot工程最终被打为了Jar包,是以可执行文件的形式出现的,其使用了Spring Boot内嵌的Tomcat作为Web服务器来运行web应用的.新版Dubbo的监控 ...

  3. HTML DOM 对象 - 方法和属性

    一些常用的 HTML DOM 方法: getElementById(id) - 获取带有指定 id 的节点(元素) appendChild(node) - 插入新的子节点(元素) removeChil ...

  4. jupyter的使用技巧

    具体安装教程参见上一篇博客. 1.有几种格式code,编码模式:markdown注释格式: 2.如果出现no module named 'XX' ,需要在anaconda prompt中使用conda ...

  5. MES目前应用很多,为什么APS计划排程系统应用很少?

    一.APS自动化计划排程能带来哪些效益? 1.提高订单准时交货率,提高客户满意度 2.缩短生产制造周期,提高生产效率 3.多品种.小批量.以销定产,快速解决插单.急单预测交期问题 4.减少物料采购提前 ...

  6. C# 将PDF转为线性化PDF

    线性化PDF文件是PDF文件的一种特殊格式,可以通过Internet更快地进行查看.线性化的PDF,在页面数量很多的情况下,更能突出表现出快速浏览的优势.下面是通过后端.NET程序实现将PDF文件转为 ...

  7. 如何在java web工程下建立存储property文件的文件夹,让Java程序直接读取

    如何在java web工程下建立存储property文件的文件夹,让Java程序直接读取: 步骤如下:

  8. IDE Goland DEBUG报错(could not launch process: decoding dwarf section info at offset 0x0: too short)

    背景: 在升级GO版本到1.11后发现Goland的Debug报错,如下:could not launch process: decoding dwarf section info at offset ...

  9. layUI中layDate控件兼容性问题(手机端没有效果,不显示)

    使用layDate插件发现在PC端无问题,然而在适配移动端时,发现点击input时,laydate渲染出的时间控件有时候没有反应,后发现只需在render里加入trigger: 'click',即可以 ...

  10. JAVA下划线、驼峰相互转换

    /** * 下划线转驼峰 * @param str * @return */ public static String lineToHump(String str) { str = str.toLow ...