---
title: "Get a decorator for your Drupal home"
url: "/articles/get-a-decorator-for-your-drupal-home"
type: article
date: 2016-03-16
updated: 2017-10-13
---

# Get a decorator for your Drupal home

#  Get a decorator for your Drupal home 

 With Drupal 8 and modern PHP, design patterns are going to be more relevant to us. This article talks about the decorator pattern for unobtrusive behavior inheritance.

 By

 [  Mateu Aguiló Bosch   ](/about/mateu-aguilo-bosch) 

 March 16, 2016

  

## Design patterns

[Software design patterns](https://en.wikipedia.org/wiki/Software_design_pattern) are general and **reusable** software design **solutions** to a defined problem. They were popularized in 1994 by the *“Gang of Four”* after their book [Design Patterns: Elements of Reusable Object-Oriented Software](https://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612).

These generic solutions are not snippets of code, ready to be dropped in your project, nor a library that can be imported and reused. Instead they are a templated solution to the common software challenges in your project. Design patterns can also be seen as **best practises** when encountering an identified problem.

With Drupal 8’s leap into modern PHP, design patterns are going to be more and more relevant to us. The change from (mostly) procedural code to (a vast majority of) object oriented code is going to take the Drupal community at large through a journey of **adaptation to the new programming paradigm**. Quoting the aforementioned *Design Patterns: Elements of Reusable Object-Oriented Software*:

\[…\] Yet experienced object-oriented designers do make good designs. Meanwhile new designers are overwhelmed by the options available and tend to fall back on non-object-oriented techniques they've used before. It takes a long time for novices to learn what good object-oriented design is all about. Experienced designers evidently know something inexperienced ones don't. What is it?

Even if you don’t know what they are, you have probably been using design patterns by appealing to *common sense*. When you learn what they are you’ll be thinking “Oh! So that thing that I have been doing for a while is called an adapter!”. Having a label and knowing the correct definition will help you **communicate better**.

## The decorator

Although there are [many](https://en.wikipedia.org/wiki/Software_design_pattern#Classification_and_list) design patterns you can learn, today I want to focus in one of my favorites: [the decorator](https://en.wikipedia.org/wiki/Decorator_pattern).

The decorator pattern allows you to do **unobtrusive behavior inheritance**. We can have many of the benefits of inheritance and polymorphism without creating a new branch in the class’ inheritance tree. That sounds like a mouth full of words, but this concept is especially interesting in the Drupal galaxy.

In Drupal, when you are writing your code, you cannot possibly know what other modules your code will run with. Imagine that you are developing a feature that enhances the `entity.manager` service, and you decide to swap core’s `entity.manager` service by your enhanced version. Now when Drupal uses the manager, it will execute your manager, which extends core’s manager and overrides some methods to add your improvements. The problem arises when there is another module that does the same thing. In that situation either you are replacing that module’s *spiced* entity manager or that module is replacing your improved alternative. There is no way to get both improvements at the same time.

This is the type of situations where the decorator pattern comes handy. You cannot have this new module inheriting from your manager, because **you don’t know** if all site builders want both modules enabled at the same time. Besides, there could be an unknown number of modules –even ones that are not written yet– that may create the conflict again and again.

## Using the decorator

In order to create our decorator we’ll make use of the interface of the object we want to decorate. In this case it is `EntityManagerInterface`. The other key component is the object that we are decorating, let’s call it **the subject**. In this case our subject will be the existing object in the `entity.manager` service.

Take for instance a decorator that does some logging every time the `getStorage()` method is invoked, for debugging purposes. To create a decorator you need to create a pristine class that implements the interface, and receives the subject.

```php
class DebuggableEntityManager implements EntityManagerInterface {

 protected $subject;

 public function __construct(EntityManagerInterface $subject) {

   $this->subject = $subject;

 }

}
```

The key concept for a decorator is that we are going to **delegate** all **method calls** to the subject, except the ones we want to override.

```php
class DebuggableEntityManager implements EntityManagerInterface {

 protected $subject;

 // ...

 public function getViewModeOptions($entity_type_id) {

   return $this->subject->getViewModeOptions($entity_type_id);

 }

 // …

 public function getStorage($entity_type) {

   // We want to add our custom code here and then call the “parent” method.

   $this->myDebugMethod($entity_type);

   // Now we use the subject to get the actual storage.

   return $this->subject->getStorage($entity_type);

 }

}

```

As you have probably guessed, the subject can be the default entity manager, that other module’s spiced entity manager, etc. In general you’ll take whatever the `entity.manager` service holds. You can use any object that implements the `EntityManagerInterface`.

Another nice feature is that you can decorate an already decorated object. That allows you to have multiple decorators adding different features without changing the inheritance. You can now have a decorator that adds logging to every method the entity manager executes, on top of a decorator that adds extra definitions when calling `getFieldDefinitions()`, on top of …

I like the [coffee making example](https://en.wikipedia.org/wiki/Decorator_pattern#Second_example_.28coffee_making_scenario.29) in the decorator pattern entry in Wikipedia, even if it’s written in Java instead of PHP. It’s a simple example of the use of decorators and it reminds me of delicious coffee.

## Benefits and downsides

One of the downsides of using the decorator pattern is that you can **only act on public methods**. Since you are –intentionally– not extending the class of the decorated object, you don’t have access to any private or protected properties and methods. There are a couple of situations similar to this one where the decorator pattern may not be the best match.

The business logic you want to override is contained in a protected method, and that method is reused in several places. In this case you would end up overriding all the public methods where that protected one is called.

You are overriding a public method that is executed in other public methods. In such scenario you would not want to delegate the execution to the subject, because in that delegation your overridden public method would be missed.

If you don’t find yourself in one of those situations, you’ll discover that the decorator has other **additional benefits**:

- It favors the [single responsibility principle](https://en.wikipedia.org/wiki/Single_responsibility_principle).
- It allows you to do the decoration during [run-time](https://en.wikipedia.org/wiki/Run_time_(program_lifecycle_phase)), whereas subclassing can only be done in [compile time](https://en.wikipedia.org/wiki/Compile_time).
- Since the decorator pattern is one of the commonly known design patterns, you will not have to thoroughly describe your implementation approach during the [daily scrum](https://www.mountaingoatsoftware.com/agile/scrum/meetings/daily-scrum). Instead you can be more precise and just say “I’m going to solve the problem using the decorator pattern. Tada!”.

## Write better designs

Design patterns are a great way to solve many complex technical problems. They are a heavily tested and discussed topic with lots of examples and documentation in many programming languages. That does **not** imply that they are your **new golden hammer**, but a very solid source of inspiration.

In particular, the decorator pattern allows you to add features to an object at run-time while maintaining the object’s interface, thus making it compatible with the rest of the code without a single change.

 Published in:

- [  Drupal Development   ](/topics/drupal-development)

 

   You must have JavaScript enabled to use this form.

## Get in touch with us

### Tell us about your project. We'd love to hear from you!

 First Name  

 Last Name  

 Your email address  

 Your organization  

 How you heard about us  

 Tell us more 

     Leave this field blank