Analysis of the three realms of PHP decoupling (a brief discussion of service containers)

Analysis of the three realms of PHP decoupling (a brief discussion of servicecontainers)

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 volume increases. ", gradually "uglyinterface, dirty implementation", the cost and difficulty of project maintenance have increased to the point where it is unsustainable, and the only option is to reconstruct or re-develop.

The first realm

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. In public The object is constructed in the function. Once it involves changes in database parameters, the modification will require a lot of work

2. The person responsible for designing the Writer class needs to perform various on DB and other classes APIBe Familiar

Is there any way to reduce coupling?

Second level (parameter dependency)

Hypothetical scenario: The database address needs to be changed frequently due to different customers, and there are many classes that call the DB (if there are dozens ), hoping 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 to create the DB class, FileSystem class, etc. first, which 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), and then Create the writer variable he wants.

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 addthe 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 statements such as $db=new DB(arg1,arg2);.

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 a 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 association array to bind the string to the constructor Certainly.

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 Analysis of the three realms of PHP decoupling (a brief discussion of service containers). For more information, please follow other related articles on the PHP Chinese website!