This article describes the five major PHP object-oriented principles (DIP). Share it for your reference, as follows:
What is dependency inversion? Simply put, it isInvert dependency to dependency interface, the specific concept is as follows:
1. The upper module should not depend on the lower module, they all depend on an abstraction (the parent class cannot rely on subclasses, they all depend on abstract classes)
2. Abstraction cannot depend on concrete, concrete should depend on abstraction.
Notice,The interface here is not a narrow interface。
Why rely on interfaces? Because the interface reflects the abstraction of the problem, and at the same time, the abstraction is generally relatively stable or relatively infrequently changing, but the concrete is volatile. Therefore, dependency abstraction is the basis for implementing code extension and binding (polymorphism) during runtime: as long as the subclass of the abstract class is implemented, it can be used by all classes. Here, we emphasize the concept of scalability. Usually, extensibility refers to extensions to 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 the unchanging and adaptable land without modifying the code. Among these five major object-oriented principles, I think that inversion of dependency is the most difficult to understand and the most difficult to achieve.
Here, take the employee class as an example
<?php
interface employee
{
public function working();
}
class teacher implements employee
{
public function working()
{
echo 'teaching...';
}
}
class coder implements employee
{
public function working()
{
echo 'coding...';
}
}
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 depends on the teacher implementation; in workB, the work relies instead 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 is still limited. Not only using interfaces, but also using factories, etc., 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 further expand the code, the dependency is written in the configuration file, indicating that workB needs a teacher object, specifically whether a program is configured correctly (such as whether the dependency class file exists) and the implementation dependent on it in the configuration is loaded. This detection program is called an IOC container.
I have seen the concept of IOC (Inversion of Control) in many articles. In fact, IOC is synonymous with the Dependence Inversion Principle (DIP). When mentioning IOC, you may also see someone mentioning concepts such as DI. DI, namely dependency injection, is generally believed to be two implementations of IOC. However, with the evolution of some introductions, the relationship between these concepts has become very vague, and some people think that IOC is DI. Some people believe that the description of dependency injection is more appropriate than that of IOC, and here we do not get involved in the relationship between these concepts.
In the classic J2EE design, the DAO layer and the Servicen layer are usually subdivided into 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 implemented through an XML configuration file. During execution, Spring establishes dependencies between objects according to the configuration file settings.
As shown in the following code
<bean scopre="prototype" class="" > <property ref="userReplyService" name="userReplyService" /> <property ref="userService" name="userService" /> <property ref="permissionService" name="permissionService" /> <property ref="friendService" name="friendService" /> </bean>
However, such settings also have problems, the configuration files will become larger and larger, and the relationships will become more and more complicated. Also, it is impossible to escape the nightmare of constantly modifying codes as the application and business changes (here is believed that configuration files are part of the code. And in actual development, there are few cases of simply modifying configuration files. Generally, if the configuration files are modified, the code will also be modified accordingly)
In PHP, there is also an implementation similar to imitating 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 implemented for the sake of implementation. In Srping, the configuration file is configured not only with a class runtime dependencies, but also with transaction management, AOP, delayed loading, etc. The consumption of PHP to implement the above features is huge. From a language level, PHP, a dynamic scripting language, is different from compiled languages in implementing some polymorphic features. Secondly, PHP, as an agile development language, emphasizes fast development, clear logic, and simpler and easier to understand code. If a framework of various design patterns is attached, it is not advisable from the perspective of technical implementation and operational efficiency. The core principle of dependency inversion is decoupling. If you deviate from this most primitive principle, it 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. But as PHP, there is currently no more complete IOC container, perhaps PHP does not need it at all.
If DIP is met:
1. Each higher-level class proposes an interface declaration for the services it needs, and the lower-level class implements this interface.
2. Each high-level class uses the service through this abstract interface.
For more information about PHP related content, please check out the topic of this site:PHP object-oriented programming tutorial》、《Complete collection of PHP array (Array) operation techniques》、《Introduction to PHP basic syntax》、《Summary of PHP operations and operator usage》、《Summary of usage of php strings》、《PHP+mysql database operation tutorial"and"Summary of common database operation techniques for php》
I hope this article will be helpful to everyone's PHP programming.