English
English
Let’s first look at a typical example. In some service registration process, in order to ensure that the service complies with a certain interface, developers will use codes similar to the following:
<code> if (!is_a($serviceInstance, MyServiceInterface::class)) { throw new InvalidArgumentException("Service must implement MyServiceInterface"); } </code>On the surface, this prevents the injection of error types during the registration phase, thus avoiding runtime errors. Indeed, this approach is a guarantee for interface isolation. But here's the question: Is it really necessary to check manually?
Starting from PHP 7, the type prompt is powerful enough:
<code> function registerService(MyServiceInterface $service) { // ... } </code>At this time, if you pass in an instance that does not match the MyServiceInterface , PHP itself will throw a TypeError . So, do we still need to manually check it again with is_a() ?
Actually, it's not necessary. Unless your code allows mixed types to be passed in, or the source of the service instance is very uncertain (such as some remote instance injection, plug-in system loading, etc.), PHP's type prompt mechanism is sufficient.
Overuse of is_a() will bring some hidden problems:
Repeated verification : The type system has been checked, and doing it manually is repeated to increase the maintenance burden.
Obstacle polymorphism : Some implementation classes may generate instances using trait or dynamic proxy methods, and the checking of is_a() may cause it to be misjudged as an illegal object.
Make container logic redundant : The responsibility of a container is to parse and inject dependencies, rather than force verification of types. Too heavy responsibility can easily lead to coupling.
It does not mean that is_a() is useless. It is still useful in the following scenarios:
Plugin system: When the extended class provided by a third party cannot be constrained using type prompts, using is_a() can fail in advance.
Dynamic service registration: For example, when reading a configuration file to dynamically instantiate the service, appropriate is_a() verification is acceptable for security reasons.
Avoid malicious injection: In large systems, some modules may be maintained by multiple teams, and using is_a() as the final defense strategy is also a bottom-up strategy.
In normal service registration logic, it is recommended to use native type prompt + automatic dependency injection whenever possible. Keep the code simple and the responsibilities single. For containers, it is enough to be able to construct objects, inject dependencies, and solve life cycles, and there is no need to shoulder the responsibility of "checking police" .
If dynamic checking is really required, it is recommended to encapsulate is_a() into a tool function and manage it in a unified manner, such as:
<code> function assertImplements($instance, string $interface) { if (!is_a($instance, $interface)) { throw new InvalidArgumentException("Instance not implemented interface: $interface"); } } </code>This not only improves readability, but also reduces coupling.
