This is in continuation to the previous post. Please note that this post will be long one, so if you have time keep reading
This pattern says “Defines attaching new responsibility to the object dynamically”.
What it says is that, some times you often require to give an object some extra/additional responsibility at some later point of time so that you can perform some thing else from it. Based on some conditions, this object should take or have some responsibility so that it can perform multiple roles in a system.
Although by reading above lines, one might get confused as this pattern would fall under Behavioral than in structural category. Well from overview, it looks like we are adding some behaviors to an object, but actually we are adding different structure via responsibility to the object at some point where its output will be in terms of behavior changes.
Take this example, since we are all humans, as soon as we enter a premises of our work place, we take up new responsibility of being an employee. As long as we are inside this premises we are identified as the Employee of that structure. When we fall out of that structure or separated from that structure, we fall back to take up old responsibility that is human responsibility. But not every human out there is capable of taking this responsibility structure called Employee due to various reasons.
Similarly as soon as we enter a car, we tend to take up a responsibility of either a passenger (broadly classified) or a driver (Specifically classified) responsibility. So that means to take up the responsibility structure as driver, one must exactly possess the knowledge about driving. So then only you can put these 2 components together to make it work perfectly.
You should note one thing is, the structures which is an added responsibility here should exactly fit into another component, not every component will fit with this responsibility component, like i can not make a dog sit in the driver seat and make it drive. Although logically it might make sense (assuming dog knows how to drive due to its extra phenomenal talent like in movies) but realistically its not preferred nor acceptable or a chaos condition 😉
With out using this pattern, we are in a big soup. The design of the system would turn out to be very complex, since for each responsibility we ought to create many new objects and then we should make those objects talk to each other. But all these would be defined statically, but later at run time it would be very tedious to define this behavior. Not only that, we can’t abide to the SOLID software design principles too. Every time there needs to be added a new behavior we need to modify the existing structure, which is a big cost for us.
Lets take the same example of being a driver who is a human too. Now what could have happen if this pattern is not used. We would be having an object of Human and another object called Driver who has replicated behaviors of humans too. So like this 2 many objects would be required, not only this any one would make the driver object to replicate behavior of a non-human as well. The whole system will be a mess.
Note that as i said in the Part 2 article that, patterns are not always the solution for a problem. So if above said problem can be easily solved and maintained for a long time, then patterns are of no use at all here. But above said system would be very difficult to design and maintain with out these patterns where several components of a system interact each other.
Lets look at the code i wrote to simulate this pattern, as i said i have written very simplistic code.
The code i am simulating here is about a bottle which we can call it as Beverage bottle, now the core structure of the bottle is same, but on different occasion or on different sub-category brand, i need to give a different coverage aka responsibility such that its depiction at the end is different.
For example, if Coca cola bottle core shape is fixed (which it is in real world) then for a Diet Coke, Normal Coke, Lime flavored, etc. flavor type categories i need to give a different coverage color or look to it. So at the end of the production line, i would get same shaped bottle (shape is a trademark of coca cola) but with different representation, look at the code now.
As you can see from the above code, i have a Beverage bottle interface which has 2 methods where one gets its default description and other gets its basic cost.
So if any vendor wants just a basic model of the Beverage bottle, they would just call these methods directly. But if they want w.r.t category of sub-brands like flavored, etc. Then lets see the responsibility structure code which we need to add to this basic model at some point or at run time.
So as you can see from the above code, i have few additional responsibility structures which i am supposed to add to the basic beverage at later point of time i.e when ever i need.
So lets look at the usage point of this pattern in below code:
Let me show you some examples in real world where we are using it knowingly or unknowingly, although i gave away few examples above, still i think picture speaks more than words:
Note: i don’t have any thing against Jobs please. I respect his talents.
- As the picture depicts, any picture can’t fit into a photo frame, like i gave away an example any thing nor any body can fit to be a car driver responsibility.
- As i gave an example of beverage bottle via a code, this picture tells you pretty much about the same scenario.
- Even gifts boxes we wrap or decorate with some thing, but every thing or any thing can’t be used to decorate. Yes it sounds it can be done logically at least but realistically it does not sound fine nor fits perfectly.
Well, that’s all dear friend i can talk about this pattern. I am sorry if it’s too lengthy, but i wanted to make every point clear.
Look out for my next post in continuation to this.
P.S: Your valuable comments, votes are well appreciated.