zoukankan      html  css  js  c++  java
  • 话说 依赖注入(DI) or 控制反转(IoC)

    话说 依赖注入(DI) or 控制反转(IoC)

     
    浏览:3641 发布日期:2014/03/20 分类:技术分享
    科普:
    首先依赖注入和控制反转说的是同一个东西,是一种设计模式,这种设计模式用来减少程序间的耦合,鄙人学习了一下,看TP官网还没有相关的文章,就写下这篇拙作介绍一下这种设计模式,希望能为TP社区贡献一些力量。

    首先先别追究这个设计模式的定义,否则你一定会被说的云里雾里,笔者就是深受其害,百度了N多文章,都是从理论角度来描述,充斥着大量的生涩词汇,要么就是java代码描述的,也生涩。

    不管怎么样,总算弄清楚一些了,下面就以php的角度来描述一下依赖注入这个概念。

    先假设我们这里有一个类,类里面需要用到数据库连接,按照最最原始的办法,我们可能是这样写这个类的:
    1. class example {
    2.     
    3.     private $_db;
    4.     function __construct(){
    5.         include "./Lib/Db.php";
    6.         $this->_db = new Db("localhost","root","123456","test");
    7.     }
    8.     function getList(){
    9.         $this->_db->query("......");//这里具体sql语句就省略不写了
    10.     }
    11.  }
    复制代码
    过程:
    在构造函数里先将数据库类文件include进来;
    然后又通过new Db并传入数据库连接信息实例化db类;
    之后getList方法就可以通过$this->_db来调用数据库类,实现数据库操作。

    看上去我们实现了想要的功能,但是这是一个噩梦的开始,以后example1,example2,example3....越来越多的类需要用到db组件,如果都这么写的话,万一有一天数据库密码改了或者db类发生变化了,岂不是要回头修改所有类文件?
    ok,为了解决这个问题,工厂模式出现了,我们创建了一个Factory方法,并通过Factory::getDb()方法来获得db组件的实例:
    1. class Factory {
    2.     public static function getDb(){
    3.         include "./Lib/Db.php";
    4.         return new Db("localhost","root","123456","test");
    5.     }
    6.  }
    复制代码
    sample类变成:
    1. class example {
    2.     
    3.     private $_db;
    4.     function __construct(){
    5.         $this->_db = Factory::getDb();
    6.     }
    7.     function getList(){
    8.         $this->_db->query("......");//这里具体sql语句就省略不写了
    9.     }
    10.  }
    复制代码
    这样就完美了吗?再次想想一下以后example1,example2,example3....所有的类,你都需要在构造函数里通过Factory::getDb();获的一个Db实例,实际上你由原来的直接与Db类的耦合变为了和Factory工厂类的耦合,工厂类只是帮你把数据库连接信息给包装起来了,虽然当数据库信息发生变化时只要修改Factory::getDb()方法就可以了,但是突然有一天工厂方法需要改名,或者getDb方法需要改名,你又怎么办?当然这种需求其实还是很操蛋的,但有时候确实存在这种情况,一种解决方式是:

    我们不从example类内部实例化Db组件,我们依靠从外部的注入,什么意思呢?看下面的例子:
    1. class example {
    2.     private $_db;
    3.     function getList(){
    4.         $this->_db->query("......");//这里具体sql语句就省略不写了
    5.     }
    6.     //从外部注入db连接
    7.     function setDb($connection){
    8.         $this->_db = $connection;
    9.     }
    10.  }
    11.  //调用
    12. $example = new example();
    13. $example->setDb(Factory::getDb());//注入db连接
    14. $example->getList();
    复制代码
    这样一来,example类完全与外部类解除耦合了,你可以看到Db类里面已经没有工厂方法或Db类的身影了。我们通过从外部调用example类的setDb方法,将连接实例直接注入进去。这样example完全不用关心db连接怎么生成的了。
    这就叫依赖注入,实现不是在代码内部创建依赖关系,而是让其作为一个参数传递,这使得我们的程序更容易维护,降低程序代码的耦合度,实现一种松耦合。

    这还没完,我们再假设example类里面除了db还要用到其他外部类,我们通过:
    1. $example->setDb(Factory::getDb());//注入db连接
    2. $example->setFile(Factory::getFile());//注入文件处理类
    3. $example->setImage(Factory::getImage());//注入Image处理类
    4.  ...
    复制代码
    我们没完没了的写这么多set?累不累?
    ok,为了不用每次写这么多行代码,我们又去弄了一个工厂方法:
    1. class Factory {
    2.     public static function getExample(){
    3.         $example = new example();
    4.         $example->setDb(Factory::getDb());//注入db连接
    5.         $example->setFile(Factory::getFile());//注入文件处理类
    6.         $example->setImage(Factory::getImage());//注入Image处理类
    7.         return $expample;
    8.     }
    9.  }
    复制代码
    实例化example时变为:
    1. $example=Factory::getExample();
    2. $example->getList();
    复制代码
    似乎完美了,但是怎么感觉又回到了上面第一次用工厂方法时的场景?这确实不是一个好的解决方案,所以又提出了一个概念:容器,又叫做IoC容器DI容器

    我们本来是通过setXXX方法注入各种类,代码很长,方法很多,虽然可以通过一个工厂方法包装,但是还不是那么爽,好吧,我们不用setXXX方法了,这样也就不用工厂方法二次包装了,那么我们还怎么实现依赖注入呢?
    这里我们引入一个约定:在example类的构造函数里传入一个名为Di $di的参数,如下:
    1. class example {
    2.     private $_di;
    3.     function __construct(Di &$di){
    4.         $this->_di = $di;
    5.     }
    6.     //通过di容器获取db实例
    7.     function getList(){
    8.         $this->_di->get('db')->query("......");//这里具体sql语句就省略不写了
    9.     }
    10.  }
    11. $di = new Di();
    12. $di->set("db",function(){
    13.    return new Db("localhost","root","root","test"); 
    14.  });
    15. $example = new example($di);
    16. $example->getList();
    复制代码
    Di就是IoC容器,所谓容器就是存放我们可能会用到的各种类的实例,我们通过$di->set()设置一个名为db的实例,因为是通过回调函数的方式传入的,所以set的时候并不会立即实例化db类,而是当$di->get('db')的时候才会实例化,同样,在设计di类的时候还可以融入单例模式。
    这样我们只要在全局范围内申明一个Di类,将所有需要注入的类放到容器里,然后将容器作为构造函数的参数传入到example,即可在example类里面从容器中获取实例。当然也不一定是构造函数,你也可以用一个 setDi(Di $di)的方法来传入Di容器,总之约定是你制定的,你自己清楚就行。

    这样一来依赖注入以及关键的容器概念已经介绍完毕,剩下的就是在实际中使用并理解它吧!

    本文如有错误,请务必指出,大家共同学习,共同进步。

    转载请注明出处。
     
    评论(12)相关
    yttsic07月07日
    我真是不明白 为什么连接数据库的时候要把连接参数写在你这个方法里?!然后再说不能这样 这样不好,哎 我看了很多例子 里边都这样说,关键是有人这样写吗?每个类需要连接了 就把参数写一遍?换地址和密码了 就把所有连接的地方的参数都改改?举这些例子的人都是这样默认大家都是这么做的?真是搞不明白。
    回复yttsic07月07日
    其实我觉得他们要比较的是他们提出的这种处理方式和我们目前用的相比 有什么好的地方,而不是举个傻叉的例子 然后说不能这样,而是要这样。真是服了他们的逻辑了。
    lmnpqrst01月12日
    请问一下楼主,最后的那个DI()容器类是怎么写呢?谢谢
    workgang12月25日
    楼主讲完了 80% 还有剩下的 20% 精华部分没有说到。
    就像您说的 在 example 里面放入 Factory工厂对象 是一种依赖,不好。
    同样的。您在 example 里面放入 DI 对象依赖 也是不好的。
    那我们应该怎么做呢?
    答案就是: 所有涉及到实例化对象的地方,都不要用 new class() 去实例化了。
    我们用一个 叫 DI 的容器对象 去实例化 所有对象。
    假设我们现在需要 用ID容器 去实例化 example 对象。
    1.  class example {
    2.     
    3.     private $_db;
    4.     function __construct(db){
    5.         $this->_db = db
    6.     }
    7.     function getList(){
    8.         $this->_db->query("......");//这里具体sql语句就省略不写了
    9.     }
    10.  }
    复制代码
    复制代码
    复制代码

    DI 对象有一个方法 ,用途是 分析类的构造函数的参数。
    这里我们分析 example 的构造函数, 发现有一个叫 db 的参数。
    DI 就会去实例化 db对象。 然后 把实例化的 db对象 传入 example 的构造函数。
    经过这个步骤。example 对象就创建出来了, 而且自动传入了 db对象。
    过程简单描述如下:
    1 将 db 对象注册到 DI 容器。
    2 DI对象分析 example 类。 发现需要一个叫 db 的对象
    3 DI查找 db 对象, 发现找到了, 实例化 db 对象。
    4 调用 example 对构造函数,传入 db。 这样 example 就实例化完成了。
    1. $example = DI->invoke('example')
    复制代码
    复制代码
    复制代码

    大概就是这样个过程吧。 
    不知道说的对不对。 呵呵。
    回复lmnpqrst01月12日
    你讲的好像挺高级的,能写的详细一点吗?我感觉面向对象的思维还不太行,能写点代码说明一下你的思路吗?谢谢
    回复liukangkk05月31日
    回复 lmnpqrst : 剩下的20%就是利用了反射机制去实例化所需要的类,随着PHP的逐步发展,从依赖注入到反射,编程风格上越来越像JAVA了。通俗的说,如果你的项目用了依赖注入,你的代码里就可能是接口满天飞了。小项目可能感觉不到优势。但如果是大项目,就会明显感觉到代码维护起来更容易了
    degesthink09月25日
    很好,讲得通俗易懂,比网上大把的用JAVA讲解的方式好多了,依赖注入其实说白了就是一种编程约定,明白了之后,在代码中自觉用起来就好了
    京伦科技2014年03月27日
    快,连说10个屌!
    啊不名字2014年03月26日
    di在phalcon框架中的应运很典型。感谢楼主分享
    eddyou2014年03月26日
    虽然不懂在说什么,但看起来很牛!
    easyfengyu2014年03月25日
    看到最后,我又有一个疑问,如果我要还要改这个容器呢?难道一个一个页面的改?最后又是一个死循环……
    回复zstxt19892014年03月25日
    给每个类设定一个 setDi(&$di)方法。这个我是在想不出在什么情况下需要改setDi这个方法名。类似于__construct,就当作一个约定吧。
    nong_zai2014年03月21日
    我把楼主的东西总结两句话:
    依赖注入:以前自己维护的东西现在让别人来处理
    控制反转:自己现在失去了对东西的维护权,让别人得到了,发生了控制权转移
    thinkphphj2014年03月20日
    我觉得单例模式+工厂模式足以,一般情况工厂类都不会变的,如果非要用依赖注入来防止可能性非常小的变化,反而得不偿失了。也许是我的境界还没到吧~
    回复zstxt19892014年03月20日
    并不是说依赖注入有多复杂,只是一个习惯问题,实际使用起来其实一点都不麻烦。
    回复HTJZ2014年03月27日
    常见是单例模式+工厂模式
    Mr_Jing2014年03月20日
    赞一个,楼主讲得通俗易懂
    xzcxin0612014年03月20日
    好像很牛逼的感觉
    返回顶部
  • 相关阅读:
    还原被删除的对象(域)
    Windows blue系列的安装
    转移active directry数据库文件
    使用指针让两个数交换
    针对被删除的AD DS对象执行授权还原
    这两天的总结
    小小问题
    程序2
    程序4
    程序1
  • 原文地址:https://www.cnblogs.com/hellowzd/p/4655631.html
Copyright © 2011-2022 走看看