I decorate the ProductRepository with a CachedProductRepository. The decorator checks Redis first, falls back to the inner repository, and caches the result. Every service that injects ProductRepository automatically gets the cached version — no changes needed.
Service decoration wraps an existing service with a new implementation while preserving the original. The decorator implements the same interface, receives the inner (decorated) service via injection, and delegates to it while adding behaviour. Configured with the AsDecorator attribute or decorates key in services.yaml. Use cases: adding caching around a repository, logging around an API client, or modifying behaviour of third-party bundle services without touching their code. Unlike inheritance: decoration works at the container level and the original service is unaware. Unlike plain composition: the container swaps the service ID so all consumers get the decorator automatically. Strong candidates discuss: decoration priority when multiple decorators exist, accessing the inner service with MapDecorated, and that this is the open/closed principle in practice.
Tests advanced DI knowledge. Candidates who modify third-party services by forking or monkey-patching do not know about decoration. Those who use it demonstrate understanding of SOLID principles and the Symfony container.