PHP解耦的三重境界（浅谈服务容器）

在完成整个软件项目开发的过程中，有时需要多人合作，有时也可以自己独立完成，不管是哪一种，随着代码量上升，写着写着就“失控”了，渐渐“丑陋接口，肮脏实现”，项目维护成本和难度上升，到了难以维持的程度，只有重构或者重新开发。

第一重境界

假设场景：我们需要写一个处理类，能够同时操作会话，数据库和文件系统。我们或许会这么写。

境界特征：可以运行，但是严重耦合

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

class  DB{      public  function  DB( $arg1 , $arg2 ){          echo  'constructed!' .PHP_EOL;      } } class  FileSystem{      public  function  FileSystem( $arg1 , $arg2 ){          echo  'constructed!' .PHP_EOL;      } } class  Session{      public  function  Session( $arg1 , $arg2 ){          echo  'constructed!' .PHP_EOL;      } } class  Writer{      public  function  Write(){          $db = new  DB(1,2);          $filesystem = new  FileSystem(3,4);          $session = new  Session(5,6);      } } $writer = new  Writer(); $writer ->write();

写法缺点：

1.在公有函数中构造对象，一旦涉及到如数据库参数的变动，修改会有很大的工作量

2.负责设计Writer类的人员需要对DB等类的各种API要熟悉

有没有办法降低耦合度？

 

第二重境界（参数依赖）

假设场景：数据库地址因为客户不同，需要经常更换，调用到DB的类很多（假如有几十个），希望即使更改了数据库地址，也不用去修改这些类的代码。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39

class  DB{      public  function  DB( $arg1 , $arg2 ){          echo  'constructed!' .PHP_EOL;      } } class  FileSystem{      public  function  FileSystem( $arg1 , $arg2 ){          echo  'constructed!' .PHP_EOL;      } } class  Session{      public  function  Session( $arg1 , $arg2 ){          echo  'constructed!' .PHP_EOL;      } } class  Writer{      protected  $_db ;      protected  $_filesystem ;      protected  $_session ;      public  function  Set( $db , $filesystem , $session ){          $this ->_db= $db ;          $this ->_filesystem= $filesystem ;          $this ->_session= $session ;      }      public  function  Write(){                } } $db = new  DB(1,2); $filesystem = new  FileSystem(3,4); $session = new  Session(5,6); $writer = new  Writer(); $writer ->Set( $db , $filesystem , $session ); $writer ->write();

虽然把DB类的构造移到了客户端，一旦涉及修改，工作量大大降低，但是新问题来了：为了创建一个Writer类，我们需要先创建好DB类，FileSystem类等，这对负责涉及Writer类的人来说，要求是很高的，他需要看很多其他类文档，一个个创建（可能还需要初始化），然后才能创建出他要的writer变量。

所以，我们希望，能有一种更好的写法，使得写Writer类的人，用一种更加快捷的接口，就能创建和调用他要的类，甚至连参数都不用填。

 

第三重境界（IOC容器）

经过前两重境界，我们希望能新增以下这些好处：

1.希望DB类，Session类，FileSystem类“拿来即用”，不用每次繁琐的初始化，比如写$db=new DB(arg1,arg2);这类语句。

2.希望DB等类型的对象是“全局”，在整个程序运行期间，随时可以调用。

3.调用DB等类型的程序员不用知道这个类太多的细节，甚至可以用一个字符串的别名来创建这样一个对象。

能够实现以上目标的就是IOC容器，可以把IOC容器简单的看成一个全局变量，并用关联数组把字符串和构造函数做绑定。

我们先实现一个容器类

1 2 3 4 5 6 7 8 9

class  Container{      public  $bindings ;      public  function  bind( $abstract , $concrete ){          $this ->bindings[ $abstract ]= $concrete ;      }      public  function  make( $abstract , $parameters =[]){          return  call_user_func_array( $this ->bindings[ $abstract ], $parameters );      } }

服务注册（绑定）

1 2 3 4 5 6 7 8 9 10 11 12

$container = new  Container(); $container ->bind( 'db' , function ( $arg1 , $arg2 ){      return  new  DB( $arg1 , $arg2 ); }); $container ->bind( 'session' , function ( $arg1 , $arg2 ){      return  new  Session( $arg1 , $arg2 ); }); $container ->bind( 'fs' , function ( $arg1 , $arg2 ){      return  new  FileSystem( $arg1 , $arg2 ); });

容器依赖

1 2 3 4 5 6 7 8 9 10 11 12 13

class  Writer{      protected  $_db ;      protected  $_filesystem ;      protected  $_session ;      protected  $container ;      public  function  Writer(Container  $container ){          $this ->_db= $container ->make( 'db' ,[1,2]);          $this ->_filesystem= $container ->make( 'session' ,[3,4]);          $this ->_session= $container ->make( 'fs' ,[5,6]);      } } $writer = new  Writer( $container );