The decorator structural pattern allows you to add new behavior to object instances dynamically. That means an object can change its behavior at run time. The interesting thing is that your objects don’t even know they’ve been changed.

The episode describes a sword class with two methods: draw and strike.

If you want your game to have a cool sword with blue flames, then instead of subclassing the sword class and overriding methods, you can instead create a decorator class that just knows how to add blue flames. This might seem like inheritance. And it is because you’ll need some inheritance somewhere in order to get your decorator classes to mimic the classes they are decorating. But this pattern shows you how to use inheritance in a different way which will allow you to combine effects such as blue flames in interesting ways.

The important part is that a sword that is being decorated looks identical to the basic sword without any decorations. Each decoration composes an instance of what it thinks is the basic class. But because code can’t tell a basic class from a decorated class, it’s possible to chain decorations. The chaining is possible because of a critical aspect of writing a behavior. Each method in a decorator needs to call the composed method of the same name at some point. It might call the composed method first and then add something new, or add something new and then call the composed method. Or maybe it calls the composed method in the middle of adding something new. the important thing is that it does call the composed method. Because the object being decorated might actually be another decoration which will want to add its own behavior.

You can even double or triple your decorations. Or more. If you have a sword decoration that adds extra damage, then you can stack that damage by adding multiple extra damage decorations.