how to apply Decorator design pattern with lagom?

Hi, How to apply the Decorator design pattern with lagom, on single instance registrations and/or collection registrations?

Example how I used to do it with a DI container from C# .Net called SimpleInjector (if same syntax were to be in lagom):

class HttpClient(ABC):
    async def send(self, request: Request) -> Response:
        pass

class ActualHttpClient(HttpClient):
    async def send(self, request: Request) -> Response:
        # Implement actual request send, e.g. with aiohttp

class LoggingHttpClientDecorator(HttpClient):
    def __init__(self, decoratee: HttpClient):
        self.__decoratee = decoratee
    async def send(self, request: Request) -> Response:
        print("Sending request")
        response = await self.__decoratee.send(request);
        print("Received response")
        return response;

container = Container()
container[HttpClient] = Singleton(ActualHttpClient)
container.RegisterSingletonDecorator[HttpClient, LoggingHttpClientDecorator](); # mimics the SimpleInjector syntax

With this code, resolving HttpClient would return LoggingHttpClientDecorator decorating ActualHttpClient. SimpleInjector also supports collection injections, e.g. injecting something like Iterable[HttpClient], and apply a decorator to all of the HttpClient instances registered to the collection.

[Eldar1205]

Thanks for your attention and collaboration with this issue 😃 I think your suggestion for decorator with lambda would requires users of this feature to do more work in the following case: Imagine the decorator has another dependency other than the decorated class, e.g. Logger, then as a user I would need to write the lambda to include that other dependency which should also be resolved from the container somehow. Now imagine I wrote that down, and my decorator was changed to have an additional dependency in the constructor - now I need to fix my lambda registration to match that as well.

An API that supports both container.register_decorator(HttpClient, LoggingHttpClientDecorator) or container.register_decorator(HttpClient, Singleton(LoggingHttpClientDecorator)) would resolve both this issues if the container would inject into LoggingHttpClientDecorator the decorated HttpClient and any other dependencies it has just with any normal registered class. Note that users should be able to apply multiple decorator registrations such that the other matter to determine the decorator chain, e.g. LoggingHttpClientDecorator decorator which is then decorated itself with CachingHttpClientDecorator

[meadsteve]

hmmm. I really like your suggestion. It’s quite easy to read. My only concern about it is that it could end up making it easy to create some construction infinite loops depending on how the decoration is implemented.

Maybe it’s worth trying out. If it doesn’t work then something like the following is also an option:

container.register_decorator(HttpClient, lambda decorated, c: LoggingHttpClientDecorator(decorated, logger=c[Logger]))

having the container passed as an argument to the lambda is a pattern I’ve used in other parts of the library so it shouldn’t be surprising.