Decorator pattern overview

- [Voiceover] The Gang of Four says that the decorator pattern attaches responsibility to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality. My simple definition of this is that the decorator pattern is all about using composition and limiting inheritance to simplify object relationships, making them easier to update or manage. So what's the process for this pattern? Well, it boils down to wrapping objects.

In fact, sometimes the decorator is called the wrapper pattern. Let's say I'm on an online system to order a car, and this system would let me choose features like the size. And let's say for example, it's a compact car. I wanna add features to this car, and rather than using inheritance, I can add decorators as features. For example, I can add navigation as a feature. I am wrapping the compact car in a navigation decorator.

If I wanted to add a sunroof, I can add a sunroof decorator, thereby wrapping the navigation. If I want to get fancy, add leather seats, I add a decorator for that. And then I wrap the sunroof. So I started off with just a compact car, but then was easily able to add just decorators. Now if I need to get the car price, I just need to call the method on the outermost decorator. Leather seats is gonna hand off computing the price to the object it decorates, which is sunroof.

When it gets the price, it will include the additional costs for the leather seats. Likewise, sunroof adds its additional cost after getting a price from navigation. All this is done at runtime and uses business logic to determine what kind of decorators are added and removed. Let's look at the class diagram. Now here we have the class diagram. At the top we have Component. That's gonna be our car. And it has Operation. And we could have operations such as get car price and get car description.

The component defines the interface for objects that can have responsibilities added to them dynamically. We also have ConcreteComponent right below it. That defines an object to which additional responsibilities can be attached. So an example of ConcreteComponent for us could be compact car or full size car. Also we have Decorator. So, in our code, we could simply name a class called car decorator. That maintains a reference to a component object and defines an interface that conform to the components interface.

And lastly we have ConcreteDecorator. For us that could be a leather seats or navigation that adds responsibilities to the component. Let's go ahead and take a look at some code to solidify this.