Re: Decorator classes

On 29/12/2016 14:44, Alexander Lisachenko wrote:

2016-12-29 16:12 GMT+03:00 Mathieu Rochette <mathieu@rochette.cc <mailto:mathieu@rochette.cc>>:

    I find that using the decorator pattern is very verbose and maybe
    something could be done about that,
    an article[1] I saw proposed a "decorates" keyword to solves this,
    here is how it might look like in PHP:

    * the constructor is optional and default to take the first
    argument and put it in $decorated
    * if the constructor is provided PHP check that $decorated is set
    and implements the decorated interface or class
    * all public methods not overridden are automatically proxied to
    the decorated object

    There is at least a few different ways to go about this, the
    previous example was just to give you a preview of what it could
    be. If there is interest I'd like to write an RFC for this :)

    What do you think about this ?

Hi! I think that language doesn't need any additional keywords for that. What you describe is pure class inheritance and it's already available in the language. It is not class inheritance, as you can see in my example, the decorator is on an interface. one point of the decorator pattern is that you don't need to know

which class (or subclass) you are decorating. any object implementing the interface (or extending the class if it's a class you are decorating) can be decorated.

To be honest I use class inheritance in Go! AOP to define decorators because of some nice features: 1. No overhead for calling non-decorated method (we can wrap only

    required methods)

I think PHP could be smart enough to do that too for non-decorated methods with the decorates keyword

1. Only one single instance of class, whereas traditional proxy and

    decorator pattern will use two instances (one for the original
    instance itself and one more instance for proxy/decorator)

I'm not sure decorator is appropriate here, in the article you are not decorating[1] your class; you are outsourcing the behavior but it's not the same

What your want can be implemented with the help of one single aspect, applied to your codebase. Then framework will automatically create decorators for every required class in your system. For logging decorator example see my blogpost here: http://go.aopphp.com/blog/2013/07/21/implementing-logging-aspect-with-doctrine-annotations/

[1] https://en.wikipedia.org/wiki/Decorator_pattern