Detailed explanation of Dependency Inversion Principle (DIP), the five major principles of object-oriented PHP

This article mainly introduces the Dependency Inversion Principle (DIP), the five major principles of object-oriented PHP. It briefly describes the concept and principle of the Dependency Inversion Principle and analyzes the relevant definitions and usage methods of the PHP Dependency Inversion Principle in the form of examples. What is needed Friends can refer to

. This article explains the Dependency Inversion Principle (DIP), the five major principles of object-oriented PHP, with examples. Share it with everyone for your reference, the details are as follows:

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

Copy after login

In workA, the work method depends on the teacher implementation; in workB, work instead relies on Abstract, 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 the configuration file, indicating that workB needs a teacher object, specifically configured by a program (such as whether the dependent class file exists) ) and the implementation it depends 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. It 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. 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>

Copy after login

However, there are still problems with such a setting. The configuration file will become larger and larger. Relationships will become increasingly 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 similar to 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 lower-level classes implement this interface.

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

Related recommendations:

Detailed explanation of the Liskov Substitution Principle (LSP) of the five object-oriented principles of PHP

The five object-oriented principles of PHP Detailed explanation of the Interface Isolation Principle (ISP)

Detailed explanation of the open-closed principle (OCP) of the five object-oriented principles of PHP

The above is the detailed content of Detailed explanation of Dependency Inversion Principle (DIP), the five major principles of object-oriented PHP_php skills. For more information, please follow other related articles on the PHP Chinese website!