Instead of using a new method, I think it will be more easy to understand if we add an options property to configure a JsonRenderer instance and continue to use the renderData method. This way we can chain calls with another decorators forever.

@adayth the idea here is to show that we can add some additional method (behaviour) to the class

A good example of chaining decorators https://sourcemaking.com/design_patterns/decorator
But maybe in the current Json/Xml example chaining is not useful at all. You will render Xml, Json or another one like Csv for example.

@adayth you could create chaining with JsonRenderer::renderData if you need.

Sorry @andrewnester probably I didn't explain clearly. Maybe a code example will be better.
To me the pull request is good as is, but I think It could be better this way.

class JsonRenderer extends RendererDecorator
{
  private $options;

  public  __construct($options = 0)
  {
    $this->options = $options;
  }

  public function setOptions($options)
  {
     $this->options = $options;
  }

  public function renderData(): string
  {
     return json_encode($this->wrapped->renderData(), $options);
  }
}

// Example
$service = new Decorator\Webservice('foo/bar');
$decorated_service1 = new Decorator\JsonRenderer($this->service, JSON_UNESCAPED_SLASHES);
$decorated_service2 = new FooRenderer($decorated_service1);
$rendered_data = $decorated_service2->renderData();

I like @adayth solution here (of course complete with type hints I would be even better). But to show chaining of decorators, this is a bad example and should be replaced with something new.

You could add a test for Decorator\Webservice, so before testing decorators, you are sure that Webservice does its job.

theres a typo here: "patters"

I like @adayth solution here (of course complete with type hints I would be even better). But to show chaining of decorators, this is a bad example and should be replaced with something new.