So, what is PSR-11? To keep this simple I will just link you to Fig:
www.php-fig.org
So, what is all that? Well, lets suffice it to say... Your DI/IOC Container implementation is the heart of your application. I'm not going to spend a lot of time explaining it. This is the cliff note version.
You need services (nearly anything in the application can be broken into either a service or service provider, its semantics really). So, how do we get said service. Well, you need an instance of said class. PSR-11 standardizes the creation of said services/providers (blah blah). Most implementations allow for 4 main paths. Concrete Factories, Invokables, Callables, Delegators. I might note here, the only difference between an invokable and a factory is an invokable is a class that takes zero (usually) constructor arguments (params) and may implement the magic method __invoke which is called any time you call the class as a functor.
In this post I am going to focus just a moment on Delegators. Why? Because of the power they introduce and the flexibility they provide within your application if your PSR-11 implementation supports them.
So, you ask... What are delegators?
Delegation is one of those esoteric programming verbs that can describe a couple different things depending on the context but mostly they are used in Aspect Oriented Programming paradigm. If you would like more reading here is a decent article:
en.wikipedia.org
So, as an example, say we are using framework A and we need to modify service B. Oh, thats easy, well, not if you do not control the creation of said service. Or is it? If your PSR-11 implementation supports delegators it can be a snap
How is that you ask? Well if it's supported then you can "delegate" the creation of that service via a construct known as a delegator factory (a factory is just a class or callable who's sole responsibility is the creation and returning of a given object instance to the container implementation). Usually, the __invoke or callable signature will have an additional argument, which will be a callback to the original service that was requested.
So, when you delegate the service its through your container implementation so that when you request the service from the container (for injection as a dependency to a consumer), you get the delegated instance instead. Now, here is a critical point. The Delegate can not be marked as final since you will need to extend that class in most cases since its considered an anti-pattern (which is debatable) to actually replace a service via delegation. The pattern, or paradigm, is intended to return the original service but with a modified context.
I should also mention, I suppose, that the reason behind ONLY returning a modified version of the original service should be allowed is really because if you need to replace the service with your own, which is different than just modifying the services creation context then you should just use a factory
Simple right?
Footnote for those reading the Wiki article I linked.
The most common implementation of the Join Points in Php will be some type of Event System. EventManager etc etc so as to provide an abstraction between the target and the listener.
PSR-11: Container interface - PHP-FIG
We're a group of established PHP projects whose goal is to talk about commonalities between our projects and find ways we can work better together.
www.php-fig.org
So, what is all that? Well, lets suffice it to say... Your DI/IOC Container implementation is the heart of your application. I'm not going to spend a lot of time explaining it. This is the cliff note version.
You need services (nearly anything in the application can be broken into either a service or service provider, its semantics really). So, how do we get said service. Well, you need an instance of said class. PSR-11 standardizes the creation of said services/providers (blah blah). Most implementations allow for 4 main paths. Concrete Factories, Invokables, Callables, Delegators. I might note here, the only difference between an invokable and a factory is an invokable is a class that takes zero (usually) constructor arguments (params) and may implement the magic method __invoke which is called any time you call the class as a functor.
In this post I am going to focus just a moment on Delegators. Why? Because of the power they introduce and the flexibility they provide within your application if your PSR-11 implementation supports them.
So, you ask... What are delegators?
Delegation is one of those esoteric programming verbs that can describe a couple different things depending on the context but mostly they are used in Aspect Oriented Programming paradigm. If you would like more reading here is a decent article:
Aspect-oriented programming - Wikipedia
So, as an example, say we are using framework A and we need to modify service B. Oh, thats easy, well, not if you do not control the creation of said service. Or is it? If your PSR-11 implementation supports delegators it can be a snap
How is that you ask? Well if it's supported then you can "delegate" the creation of that service via a construct known as a delegator factory (a factory is just a class or callable who's sole responsibility is the creation and returning of a given object instance to the container implementation). Usually, the __invoke or callable signature will have an additional argument, which will be a callback to the original service that was requested.So, when you delegate the service its through your container implementation so that when you request the service from the container (for injection as a dependency to a consumer), you get the delegated instance instead. Now, here is a critical point. The Delegate can not be marked as final since you will need to extend that class in most cases since its considered an anti-pattern (which is debatable) to actually replace a service via delegation. The pattern, or paradigm, is intended to return the original service but with a modified context.
I should also mention, I suppose, that the reason behind ONLY returning a modified version of the original service should be allowed is really because if you need to replace the service with your own, which is different than just modifying the services creation context then you should just use a factory
Simple right?
Footnote for those reading the Wiki article I linked.
The most common implementation of the Join Points in Php will be some type of Event System. EventManager etc etc so as to provide an abstraction between the target and the listener.
Last edited:
