While talking about extendibility in my last post I pondered about some ways of adding additional functionality to an object. As soon as I said “adding additional functionality”, I’m pretty sure many of you may have shouted “Decorator” in your minds. Yes but what about “Template Method” and “Strategy”? Can’t they be used for this purpose as well?
Let’s discuss what each design pattern does in brief so we could talk about their applicability. My objective is not to repeat design patterns here but to shed a little light in to thinking that goes before choosing them. So if you want to read an extensive discussion of these three design patterns, this isn’t the place.
What does the decorator do (most commonly used version of it)? It adheres to a common interface which it shares with the object it decorate and wraps the object mediating all messages to and from that object so that it could provide the extended functionality. So it forces you to code for the interface rather than concrete types - which is what you should be doing ideally. What’s good about it is you can get rid of it at runtime as you want. It’s just as adding a new skin to your object – and removing.
So when would you want to d this? When you want to reuse decorations and you want it to be dynamic. i. e. you don’t want to sub class because you’ll end up sub classing a large number of classes to add the same code or you want to be able to add-remove this behavior at runtime without affecting other objects. Or you simply can’t subclass it as it’s a sealed class!
What does the “Template Method” do? It calls abstract or virtual methods insides an algorithm so subclasses could override those methods to provide their own functionality. This allows you to code with more specifically typed code but if you have it, you can’t get rid of it in run time. So this is changing guts.
So when would you want to do this? When subclasses have their own way of doing certain little things but as a whole the functionality could be reused and to provide hook up points in your code so subclasses can override certain functionalities of the base. When you are changing guts, you should be working with your own code.
And finally what does the “Strategy” do? It makes clients commit to an interface to depend for certain operations; there by making it possible to change those operations by changing the object that represents that interface. This is a real dynamic way of doing things. This client is the one that we are planning to add additional functionality. This is like having your guts out side so they could be changed without affecting the other parts of your body!!
When should you be using this? When you want to encapsulate the implementation/behavior of your operations or when you want to interchange the behavior of your operations or when there are related classes which want to re use interchangeable common behaviors or when the behavior of an object should be changed based on conditions.
The “Template Method” and the “Strategy” are behavioral patterns; which means they deal with the way objects interact and distribute responsibility, “Decorator” which is a structural pattern deals with compositions of objects.
So the next time when extendibility hits you, ask yourself the question, “Should I be changing the sin, you should I change the guts”?
No comments:
Post a Comment