Sample code of the triple realm of PHP decoupling (a brief discussion of service containers)

This article mainly introduces the relevant knowledge of the three realms of PHP decoupling (a brief discussion of service containers). Has very good reference value. Let’s take a look with the editor below

Before reading this article, you need to master: PHP syntax, Object-oriented

In the process of completing the development of the entire software project, sometimes it requires the cooperation of multiple people, and sometimes it can be completed independently. No matter which one it is, as the amount of code increases, it becomes "out of control" as the code is written. Gradually, "ugly interfaces, dirty implementations" have gradually increased the cost and difficulty of project maintenance, reaching the point where it is unsustainable and the only option is to refactor or re-develop.

The first level

Hypothetical scenario: We need to write a processing class that can operate sessions, databases and file systems at the same time. We might write this.

Realm characteristics: It can run, but it is severely coupled

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();

Writing disadvantages:

1. Construct an object in a public function. Once it involves changes to database parameters, modifications will require a lot of work.

2. The person responsible for designing the Writer class needs to be familiar with various API of DB and other classes.

Is there any way to reduce coupling? Spend?

The second level (parameter dependency)

Hypothetical scenario: The database address needs to be changed frequently because of different customers, and the class called to DB There are many (if there are dozens), and I hope that even if the database address is changed, the code of these classes will not need to be modified.

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();

Although the construction of the DB class has been moved to the client, once modifications are involved, the workload is greatly reduced, but a new problem arises: in order to create a Writer class, we need First create the DB class, FileSystem class, etc. This is very demanding for the person responsible for the Writer class. He needs to read many other class documents and create them one by one (may also need to be initialized) before he can create them. The required writervariable.

So, we hope that there will be a better way of writing, so that people who write the Writer class can use a faster interface to create and call the class they want, without even filling in the parameters. .

The third realm (IOC container)

After the first two realms, we hope to add the following benefits:

1. I hope that the DB class, Session class, and FileSystem class can be used "out of the box" without tedious initialization every time, such as writing $db=new DB(arg1, arg2);This type of statement.

#2. It is hoped that DB and other types of objects are "global" and can be called at any time during the entire program running.

3. Programmers who call DB and other types do not need to know too many details of this class, and can even use an alias of string to create such an object.

What can achieve the above goals is the IOC container. You can simply regard the IOC container as a global variable and use the associated array to construct the string and Function does binding.

We first implement a container class

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);
 }
}

Service registration (binding)

$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);
});

Container dependencies

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);

The above is the detailed content of Sample code of the triple realm of PHP decoupling (a brief discussion of service containers). For more information, please follow other related articles on the PHP Chinese website!