PHP Master | Inversion of Control - The Hollywood Principle

Core points

• The concept of control inversion (IoC) is more broad than dependency injection (DI), which is just a specific application case for IoC that takes advantage of IoC. DI drives class design to adopt external collaborators, provided by the surrounding environment; while IoC transfers responsibilities between components and external environments.
• IoC, also known as the Hollywood Principle, can significantly help develop scalable, highly decoupled program modules. It allows the external environment to implement all necessary logic, thereby simplifying the implementation of the module.
• Observer mode is a classic example of IoC. It allows a highly decoupled body to perform some specific tasks without affecting the surrounding environment, while an external observer implements the logic required to handle events triggered by the body.
• IoC is a simple and powerful programming method that creates decoupled, orthogonal systems whose components can be easily isolated from tests. It is not limited to managing class dependencies, but can also be effectively used in event-driven design.

Many programmers (myself included, so this is what I publicly mea culpa) think that inversion of control (IoC) is just a synonym for dependency injection (DI). There is a rather intuitive reason for this idea: if the purpose of DI is to facilitate the design of classes so that its external collaborators are provided by the surrounding environment, rather than looking for them in turn, then this process can be effectively considered as an IoC form. However, while the equation DI = IoC is generally valid, the concept of controlling inversion itself is actually much broader. In fact, DI can be said to be a specific use case that takes advantage of IoC, but it is far from the only one. This brings us back to the starting point; if DI is just a model that relies on the advantages of IoC, then what exactly is IoC? Traditionally, application components are designed to operate and control execution environments, and this approach works well to some extent. For example, a logging module may be implemented to record data into a file, and how and when data is recorded is completely controlled by the module. A log file (in this case part of the environment) is just an external, passive element that does not affect how the module works. But suppose we need to extend the functionality of the module and enable it to additionally log data to the database, or even eventually via email. Upgrading the module to expose additional functionality will increase its complexity, and it will become increasingly bloated as the logic required to handle these extra tasks is packaged behind the same API. This approach works, but it cannot be extended at all. This situation can be solved in a fairly simple way. Rather than having the module fully responsible for logging data to multiple endpoints, we can shift the responsibility directly to the external environment. The implementation of the module will be kept very simple and limited to acting as a simple event scheduler. On the other hand, the environment will be responsible for implementing all the logic required to record data to an endpoint that is completely independent from the module in question. Not surprisingly, the process of reversing these responsibilities between components and environments is formally called control inversion (or in easier terms, Hollywood principles), and when developing scalable, highly decoupled program modules , its implementation can be a real improvement.Of course, IoC is a language-independent paradigm, so it can be easily used in the PHP world.

Implement control reversal—observe the object of the field

IoC is indeed everywhere, so it is easy to find its production implementation. The first use case that comes to mind is dependency injection, but there are many other equally representative use cases, especially in the field of event-driven design. If you want to know what parallel universes IoC works in with event handling mechanisms, consider a classic case in the GoF library: Observer Pattern. Observers are used almost anywhere, even on the client side through JavaScript, and they are prominent examples of the IoC concept; there is a highly decoupled body focusing on performing a few narrow tasks without contaminating the surroundings, while a Or multiple external observers are responsible for implementing the logic required to handle events triggered by the subject. How to deal with events, or even new events, is entirely the responsibility of the observer, not the responsibility of the subject. An example might be a great way to make my previous lengthy statement clearer. So, suppose we have implemented a primitive domain model that defines a one-to-many relationship between blog posts and comments. In this case, we will be intentionally ambitious and enable the model to send emails to notify the system administrator when new comments are added to the post. Honestly, implementing such functionality without resorting to IoC would actually be a mess because we will ask the domain object to do something beyond its scope. Instead, we can take an IoC-based approach and define the following domain class:

(The code example is omitted here because this part of the content has nothing to do with the pseudo-originality required by the question and is too long.)

Trust control to the external environment - realize comment notification service

Building an observer service that triggers email notifications when adding new comments to a blog post is a simple process that simplifies to define a class that implements the relevant update() method. (The code example is also omitted here, for the same reason as above.)

Summary

Control inversion is often considered an obscure concept, especially in PHP, where many developers tend to associate it with ordinary dependency injection, but it is a simple and powerful way to program, If implemented correctly, it is an excellent way to create a decoupled, orthogonal system whose components can be easily isolated from tests. If you use dependency injection in your application (you are indeed using it, right?), then you should feel that your programmer instinct is well satisfied because you are already taking advantage of the benefits that control inversion provides. However, as I've tried to demonstrate before, there are many situations that fit this approach besides managing class dependencies in the right way. Event-driven design is of course a good example.

(The FAQ part is omitted here, the same reason as above.)

The above is the detailed content of PHP Master | Inversion of Control - The Hollywood Principle. For more information, please follow other related articles on the PHP Chinese website!