67: Design Patterns: Decorator.

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. Listen to the episode for more about this pattern or read the full transcript below. Transcript The basic description says that this pattern lets you attach additional responsibilities to an object dynamically which provides a flexible alternative to subclassing. Subclassing is just another way to describe creating a derived class. Check out episodes 24 through 27 for more information about inheritance and creating derived classes. The biggest problem with inheritance is that the object relationships are setup at compile time. If you want an object to sometimes have different behavior and sometimes keep its current behavior, then inheritance is probably not the best choice. You should consider this decorator pattern. Just to be clear, use inheritance when you want to change the behavior of all your instances of the new derived class. If you want different behaviors, you’ll need different derived classes. And consider the decorator pattern when you want to add behavior. In a way, this can be seen as changing behavior. But, you’ll understand the intended purpose better if you think of this pattern as helping you to add new behaviors. An example will help make this more understandable. In the adventure game that I like to use for examples, let’s say we need swords for weapons. Now this adventure game has lots of magic and enchantments. What happens if you enchant a sword? First, we need to look at the basic class or interface that describes the basic sword. What are its methods? The public methods. For our example, let’s say there are only two methods, draw and strike. Maybe a real game will have more but these will work for this example. What does it mean when you draw a sword? Simple, right? That’s just the action of grabbing the sword and pulling it out of its scabbard. Or pulling it out of the character’s belt if that’s all the character has available. And strike means to swing the sword at an enemy and possibly do some damage. Now, if you wanted to, you could create a blueFlameSword class that derived from the sword clas