The decorator pattern is a design pattern that allows to modify the behavior of an individual object without affecting the behavior of other objects from the same class. In Symfony applications, service decoration allows you to change the behavior of some service without replacing it or modifying it for other parts of the application.
You can already configure service decoration using YAML, XML and PHP. In Symfony 6.1 we're adding the option to configure decoration using PHP attributes.
Consider the common case where you want to decorate a service (e.g. Mailer
)
with a new service that adds logging capabilities to it (e.g. LoggingMailer
).
This is how you can configure decoration with PHP attributes:
1 2 3 4 5 6 7 8 9 10 11
// src/Mailer/LoggingMailer.php
namespace App\Mailer;
// ...
use Symfony\Component\DependencyInjection\Attribute\AsDecorator;
#[AsDecorator(decorates: Mailer::class)]
class LoggingMailer
{
// ...
}
The #[AsDecorator]
attribute supports all the extra options that you might need:
1 2 3 4 5 6 7 8 9 10 11
// ...
#[AsDecorator(
decorates: Mailer::class,
priority: 10,
onInvalid: ContainerInterface::IGNORE_ON_INVALID_REFERENCE,
)]
class LoggingMailer
{
// ...
}
If you need to access the decorated service inside the decorating one, add the
#[MapDecorated]
attribute to any of the service constructor arguments:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
// ...
use Symfony\Component\DependencyInjection\Attribute\AsDecorator;
use Symfony\Component\DependencyInjection\Attribute\MapDecorated;
#[AsDecorator(decorates: Mailer::class)]
class LoggingMailer
{
public function __construct(#[MapDecorated] Mailer $originalMailer)
{
// ...
}
// ...
}
Love this. Wish this was available in 5.4 / 6.0. Very useful indeed.
@Andrew no. New features are never backported in maintenance branches.
If you want to use service decoration in 5.4/6.0, you'll need to use a config file.