A use-case for events on a service locator is rare. The most obvious would be logging, but there may be others, good or bad. Still, this should illustrate a more flexible, extensible, and maintainable architecture based around the SRP and decorators.
- Locators don't need access to the cross-cutting concerns anymore, reducing the number of dependencies and increasing maintainability and testability.
- Handles cross-cutting concerns, that can make the code very complex otherwise, in a clean way.
- All the concerns are easily composable and the result is a SOLID approach towards them.
- The decorator pattern also allows us to add or remove concerns later at one central location without having to change the business code.
- The locator can be tailored to the application itself and end up being very small and easily understandable.
- We need some additional code and extra classes, which might be too much for small applications and the indirection of handling cross-cutting concerns might be confusing.
- While other languages don’t need this because of their support for AOP and annotations (Spring for Java for example) this is necessary in PHP because we don’t have these features without a
PECL
extension.
HT: @beberlei