A brief discussion on decoupling of code architecture in PHP

PHP briefly talks about the decoupling of code architecture. This article mainly introduces the three realms of PHP decoupling and related knowledge of service containers. Has very good reference value. I hope to be helpful.

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 interface, dirty implementation", the cost and difficulty of project maintenance increased to the point where it was unsustainable, and the only option was 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 .Construct objects in public functions. Once it involves changes in database parameters, modifications will require a lot of work.

2. Responsible for designing the Writer class Personnel need to be familiar with various APIs such as DB

Is there any way to reduce the degree of coupling?

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 to 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 (and may need to be initialized) before he can 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 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 a string alias 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 an associative array to bind the string to the constructor.

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 dependency

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

Related recommendations:

Yii2 The data between the two modules needs to call each other. How to design to minimize the coupling?

Interface abstract class A brief description of using interfaces, abstract classes, and ordinary base classes to implement "interface-oriented programming" and "coupling methods" in PHP

Understanding of PHP coupling design pattern_PHP tutorial

The above is the detailed content of A brief discussion on decoupling of code architecture in PHP. For more information, please follow other related articles on the PHP Chinese website!