Hello.
In this video, we're going to talk about the topic 41.
What is the decorator design pattern?
The character is a design partner that dynamically adds extra functionality to an existing object without
affecting the behavior of other objects from the same glass.
Let's start with something simple here we have a class that reads information about people from some
data source.
This class is nice, simple and focused.
At some point, we are asked to add an optional feature of logging.
Human elements have been read that's added to this class.
It was such a pretty class, and now it grew large and ugly.
Well, never mind.
At least it does what it's supposed to do.
Soon after that change, we are asked to add one more optional feature to be able to limit data to some
given count of people.
Let's try to add this.
This cult is terrible now.
This class has a big chunks of logic which will or will not be executed depending on the flags.
Its logic, so simple before, is no mercy and complex.
It takes more parameters than it may need.
For example, we want Mick Gallagher if logging is not enabled and we won't need the account to meet
if the meeting is not enabled, it would be a nightmare to test this class as more and more extra features
are required to be added to this class.
It will keep growing, becoming an unmanageable mess that no one wants to work with.
It's time to introduce the decorator design pattern.
This pattern allows adding some behaviour to an object dynamically without touching its gold.
If you know the open closed principle from solid, you know it's a good thing.
It also allows us to keep the single responsibility principle happy first.
That's reverted this class to how it was before changes.
Beautiful in its simplicity.
Now let's add a logging decorator across it will decorate the people, decorate their houses.
The ability of logging, implementing the decorate or design pattern boils down to two steps making
the decorator implement the same interface as the decorated object and making the decorator own an object
implementing this interface.
It will be the creative class itself or another decorator, which allows us to compose many decorators
together.
Let's see this in cold.
As you can see, the decorator owns an object that it wants to decorate, it implements the same interface
in the real method that comes from this interface.
It goes well, whatever implementation is provided, but it adds only to something from itself.
In this case, it writes to a dog.
Remember that the decorated reader doesn't need to be the plain people.
They carry their object.
It can be anything implementing the AI people data reader interface, including unaware decorator.
Of course, at some point, one of the decorators in the structure must own the basic decorated object
of people data reader type.
Now, let's add the decorator that will be limiting the count of returned person objects.
Great.
We can now compose those decorators to our liking.
Let's create an object that reads people data, logs the original count and then limits it.
Here, the real magic happens, each decorator takes an object implementing the AI people data reader
interface as a parameter, but also implements this interface itself.
It means we can pass a decorator as a parameter to other decorator stacking their functionalities.
That's why this final object will be able to both log and limit the count of elements.
Here you can see that the count has been limited and here that originally five elements has been right.
Please be aware that the order of the decorators creation matters if we turn to this cold to this.
The result will be different because the limiting the Reid method was executed before the logging decorators
with method.
From the point of view of the logging decorator, the amount of data will be free, not five as before,
because the data was limited before it was given to the logging decorator.
The features of logging and limiting are optional, but which the decorator pattern?
It's easy to choose what we need.
Let's create a people data reader that only logs some information, but it does not lead me to the count.
Now, in the result, we see all five elements.
In other words, the result was not limited because here we create only the logging the crater.
And now let's create an object that does not log, but it does limited the data.
As you can see, there is no log string in the result, which we have been seeing before.
All right.
As you can see, the decorator pattern allows us to easily art functionality to objects without touching
the original glasses.
So it's very much in line with the open closed principle.
It also helps us to be in line with the single responsibility principle.
As each class now has a very focused responsibility, the reader class only reads the data.
The logging the great or simply adds the logging feature and the limiting the greater the data, those
gases would be easy to test, maintain and generally pleasant to work with.
During the interview, you can be asked What are the benefits of using the decorator or design pattern?
The decorator pattern allows us to easily out functionality to objects without touching the original
glasses.
It allows us to keep glasses simple.
It makes it easy to tuck functionalities together, building complex objects from simple glasses.
It helps us to be in line with both open closed principle and single responsibility principle.
The glasses extended with the decorating design pattern would be easy to test and maintain.
Oh right.
I hope you liked this pattern.
Thank you for your attention, and I'll see you in the next video.