Detailed explanation of PHP dependency inversion case

This time I will bring you a detailed explanation of the PHP dependency inversion case. What are the precautions for PHP dependency inversion? . The following is a practical case, let's take a look.

What is dependency inversion? To put it simply, inverts the dependency relationship to dependency interface. The specific concepts are as follows:

1. The upper module should not depend on the lower module. They all depend on an abstraction (parent Classes cannot depend on subclasses, they all depend on abstract classes)

2. Abstraction cannot depend on concrete, concrete should depend on abstraction.

Note that the interface here is not a narrow interface.

Why rely on interfaces? Because the interface embodies the abstraction of the problem, and because abstraction is generally relatively stable or changes relatively infrequently, concrete is changeable. Therefore, dependency abstraction is the basis for implementing code extension and runtime binding (polymorphism): as long as a subclass of the abstract class is implemented, it can be used by all users of the class. Here, the concept of scalability is emphasized. Usually extensibility refers to the expansion of known behaviors. When talking about interfaces, it is also mentioned that interfaces should be relative. This tells us that no matter how advanced the design pattern is used, it is impossible to achieve an ever-changing situation without modifying the code. Among the five principles of object-oriented, I think dependency inversion is the most difficult to understand and implement.

Here we take the employee class as an example

<?php
interface employee
{
  public function working();
}
class teacher implements employee
{
  public function working()
  {
    echo &#39;teaching...&#39;;
  }
}
class coder implements employee
{
  public function working()
  {
    echo &#39;coding...&#39;;
  }
}
class workA
{
  public function work()
  {
    $teacher = new teacher();
    $teacher->working();
  }
}
class workB
{
  private $e;
  public function set(employee $e)
  {
    $this->e = $e;
  }
  public function work()
  {
    $this->e->working();
  }
}
$worka = new workA;
$worka->work();
$workb = new workB;
$workb->set(new teacher());
$workb->work();

In workA, the work method relies on teacher implementation; in workB, work instead relies on abstraction, so that the required objects can be passed in through parameters. . The above code achieves a certain degree of decoupling through the interface, but it is still limited. Not only using interfaces, but also using factories can also achieve a certain degree of decoupling and dependency inversion.

In workB, the teacher instance is passed in through the set method, thus realizing the factory mode. Since such an implementation is still hard-coded, in order to achieve further expansion of the code, write this dependency in Configuration File, indicating that workB needs a teacher object, specifically configured by a program (as shown) Whether the dependent class files exist) and the implementation that is depended on in the loading configuration. This detection program is called an IOC container.

The concept of IOC (Inversion of Control) has been seen in many articles. In fact, IOC is a synonym for Dependence Inversion Principle (DIP). When mentioning IOC, you may also see someone mention concepts such as DI. DI, that is, Dependency Injection, is generally believed that dependency injection (DI) and dependency lookup (DS) are two implementations of IOC. However, with the evolution of some general concepts, the relationship between these concepts has become blurred, and some people think that IOC is DI. Some people think that the description of dependency injection is more appropriate than IOC, and the relationship between these concepts will not be entangled here.

In classic J2EE design, the DAO layer and Servicen layer are usually subdivided into the interface layer and implementation layer, and then the dependencies are configured in the configuration file. This is the most common DIP application. The Spring framework is a good IOC container, which strips control from the code to the IOC window. This is achieved through XML configuration files. Spring establishes dependencies between objects according to the settings in the configuration file during execution.

As shown in the code below

<bean scopre="prototype" class="cn.notebook.action.NotebookListOtherAction" id="notebookListOtherAction">
  <property ref="userReplyService" name="userReplyService" />
  <property ref="userService" name="userService" />
  <property ref="permissionService" name="permissionService" />
  <property ref="friendService" name="friendService" />
</bean>

However, there are still problems with such a setting. The configuration file will become larger and larger, and the relationship between them will become more and more complex. We also cannot escape the nightmare of constantly modifying the code as the application and business change (here the configuration file is considered to be part of the code. And in actual development, it is rare to simply modify the configuration file. Generally, if the configuration file is modified, the code Corresponding modifications will also be made)

In PHP, there is also an implementation that imitates Spring, that is, the dependencies are written in the configuration file, and the required objects are generated through the configuration file. I think such code is still implemented for the sake of implementation. In Srping, the configuration file configures not only the runtime dependencies of a class, but also transaction management, AOP, lazy loading, etc. To achieve the above features in PHP, the consumption is huge. From a language perspective, dynamic scripting languages ​​like PHP are different from compiled languages ​​in implementing some polymorphic features. Secondly, PHP, as an agile development language, emphasizes rapid development, clear logic, and simpler and easier-to-understand code. If various design pattern frameworks are added, it is not advisable from the perspective of technical implementation and operating efficiency. The core principle of dependency inversion is decoupling. To deviate from this most primitive principle is to put the cart before the horse.

In fact, many design patterns already imply the principle of dependency inversion. We are also doing some dependency inversion work intentionally or unintentionally. It's just that as PHP, there is currently no relatively complete IOC container, maybe PHP doesn't need it at all.

If DIP is met:

1. Each higher-level class proposes an interface declaration for the services it requires, and the lower-level class implements this interface.

2. Each high-level class uses services through this abstract interface.

I believe you have mastered the method after reading the case in this article. For more exciting information, please pay attention to other related articles on the php Chinese website!

Recommended reading:

Detailed explanation of steps to implement multi-image upload with Bootstrap PHP

Detailed explanation of steps to implement shopping cart function with CI framework

The above is the detailed content of Detailed explanation of PHP dependency inversion case. For more information, please follow other related articles on the PHP Chinese website!