Decorator pattern in open source code

In some open source repositories that contain a small number of maintainers are common to see classes as final, it happens because they can make modification without complex Backward Compatibility Promise, But on the other hand it keeps code a bit “complicated” to modify!

But well it is not so complicated since they implements interfaces and use composition in the code 😁, and here starts the beneficial of Decorator pattern 💅.

Open source code

I was looking for some project that has a good number of users, Then I choose EasyAdminBundle as example, it has more then +18k users and 4k starts

the piece of code that I gonna use is AdminUrlGenerator.php, and we gonna add a dispatch event when the generate method is called.

Creating a decorator

As the AdminUrlGenerator.php is a final class, it is not possible to extends this class and overite generate method, and in this case an alternative is use a decorator.

<?php

declare(strict_types = 1);

namespace App\Decorator;

use EasyCorp\Bundle\EasyAdminBundle\Provider\AdminContextProvider;
use Symfony\Contracts\EventDispatcher\EventDispatcherInterface;
use App\Event\UrlGeneratedEvent;

final class AdminUrlGeneratorDecorator implements AdminContextProvider
{
    public function __construct(
      private AdminUrlGenerator $adminUrlGenerator,
      private EventDispatcherInterface $event,
    ) {
    }

    public function generateUrl(): string
    {
          $url = $this->adminUrlGenerator->generate();
          $this->event->dispatch(new UrlGeneratedEvent($url));

          return $url;
    }

    public function setRoute(string $routeName, array $routeParameters = []): self
    {
        $this->adminUrlGenerator->setRoute($routeName, $routeParameters);

        return $this;
    }

    public function get(string $paramName): mixed
    {
        return $this->adminUrlGenerator->get($paramName);
    }

    //....
}

Breaking Down AdminUrlGeneratorDecorator class

<?php

final class AdminUrlGeneratorDecorator implements AdminContextProvider

Here we are creating the decorator and implementing the same interface used in AdminUrlGenerator class, it is important because this class is injected via __construct on ClassXYZ via AdminContextProvider, and as both class implements the same interface we can choose which class we want to in inject and in our case we gonna inject the new class created (AdminUrlGeneratorDecorator)

<?php

    public function __construct(
      private AdminUrlGenerator $adminUrlGenerator,
      private EventDispatcherInterface $event,
    ) {
    }

• AdminUrlGenerator is the original class that we want to modify the behavour
• EventDispatcherInterface is the Symofony event class, we gonna use this inside of method that we want to overite.

<?php
    public function generateUrl(): string
    {
          $url = $this->adminUrlGenerator->generate();
          $this->event->dispatch(new UrlGeneratedEvent($url));

          return $url;
    }

It is the method that we want to modify, on the first line we are calling the original method to generate the url. the second line is dispatching our event and in the last one we are returning the url generated by original method.

<?php
    public function setRoute(string $routeName, array $routeParameters = []): self
    {
        $this->adminUrlGenerator->setRoute($routeName, $routeParameters);

        return $this;
    }

    public function get(string $paramName): mixed
    {
        return $this->adminUrlGenerator->get($paramName);
    }

    //....

Maybe you were asking yourself, “why do I need those methods if I just want to change generate method?”

It is needed because AdminContextProvider is forcing to implement those methods. and this case we must implement them and call the original implementation, like I did with setRoute and get methods

Just to simplify the example I did not add all methods, But you must add all of them.