Rename *ProxyTrait/$inner -> *DecoratorTrait/$decorated?

Created on 27 May 2023, about 1 year ago
Updated 18 June 2023, about 1 year ago

Problem/Motivation

In HuxModuleHandler I see a property $this->inner.
There is also a trait HuxModuleHandlerProxyTrait.

To me, this looks more like the decorator pattern.
Am I missing something?

This actually got me back to learn about the difference.
https://doeken.org/blog/decorator-vs-proxy-pattern
https://stackoverflow.com/questions/18618779/differences-between-proxy-a...
Before that I thought "Proxy" does not really have a strict definition.

Imo "decorator" is more applicable than "proxy" here.

So:
- $inner could be renamed to $decorated.
- *ProxyTrait could be renamed to *DecoratorTrait.

Also, I think the HuxModuleHandlerProxyTrait could become a base class. But no strong opinion.
This also raises the question whether the properties should be private or protected. Currently some are private, others protected.
If the `$decorated` in the base class is private, the child class has to call parent::invoke() instead of $this->decorated->invoke().

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Are the trait and the property part of the public API? Do we expect any other modules to use them directly?

Data model changes

πŸ“Œ Task
Status

Closed: works as designed

Version

1.2

Component

Code

Created by

πŸ‡©πŸ‡ͺGermany donquixote

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @donquixote
  • πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

    HuxModuleHandlerProxyTrait exists only to satisfy the implementation of all of ModuleHandlerInterface in a code-clean way, rather than polluting HuxModuleHandler.

    The API of HuxModuleHandlerProxyTrait is such that there is a symbiosis with HuxModuleHandler. The trait is effectively sealed; is not allowed to be used by any other class. HuxModuleHandlerProxyTrait even has methods that are overridden by HuxModuleHandler, and are thusly never invoked.

    As for the 'proxy' naming, I dont exactly recall why its named that. Maybe a refactor, maybe legitimate reasoning, but its inconsequential in the end, per the sealed rationale.

    HuxModuleHandler itself is a decorator, and the "inner" convention comes from Symfony itself.

    raises the question whether the properties should be private or protected.

    This also does not matter as HuxModuleHandler is final, nobody is permitted to use extend or read it.

    I originally had the plan to only call methods on inner from the trait, but you can see I did end up calling it from HuxModuleHandler (perhaps out of laziness). Ideally HuxModuleHandler reach out to the trait methods instead.

    --

    Addressing this issue in the context of the core-implementation, Hux features would be brought into ModuleHandler proper so this trait and the decorator would not be present.

  • πŸ‡©πŸ‡ͺGermany donquixote

    Addressing this issue in the context of the core-implementation, Hux features would be brought into ModuleHandler proper so this trait and the decorator would not be present.

    True.

    I think it is worthwhile to review some design choices if we plan to move into core, but for this one it seems not really necessary.

    I mostly raise these issues because I wanted to work on the new attribute interface, and I like to do some clean-up in preparation.
    Also, to have a nice starting point for core.

  • πŸ‡©πŸ‡ͺGermany donquixote

    I found that *Decorator(Base) and ->decorated-> is more common in Drupal core.
    I find only one ->inner-> and no *ProxyBase or *ProxyTrait.

    Rename now part of πŸ“Œ Combined refactoring and attributes interface Needs review

  • Status changed to Closed: works as designed about 1 year ago
  • πŸ‡¦πŸ‡ΊAustralia dpi Perth, Australia

    Closing based on

    Makes things consistent, for maintaining Hux.

    Will not be necessary, if in core.

Production build 0.69.0 2024