Strategy Pattern vs. Case Statement
I have seen this mentioned in a lot of refactoring articles. I find it quite difficult or maybe difficult isn't the word but it's not appealing to make such a change to code. It's one of those when you refactoring and it takes quite a while to refactor the code just to get it doing what it already did.
The benefit will come when you have to come and change the code again. Adding the strategy pattern allows you to really separate the code and dependencies. The main benefit of this is that when you have to add a new strategy or type then you can add it in and it doesn't effect the other classes because it is decoupled through the use of the interface or abstract class.
The one thing I would say is that I don't often see much code using large case statements, I find that people usually use big sprawling if statements.
Using a strategy pattern instead of a case statement I found is quite difficult to explain to people, it can be difficult to justify especially to programmers who don't know what the strategy pattern is (by name if not by logic). Initially it seems like you are needlessly creating etc classes to do what they could do by using an if or case statement. The problem I find with if statements is that they tend to grow and start sprawling in one method and then the same logic starts appearing in another method and the dependency on different classes grows, especially when you add a new case or if statement.
The real sign you should consider replacing those case/if statement is when adding one new type or if/case selection takes ages, ending with lots of similar changes.
If you are thinking or wanting to use the strategy pattern it can be added a lot easier when you are writing some new code or a new piece of code. I have used it recently and not just because I wanted to use the strategy pattern (put down that golden hammer) I did it without really remembering it was the strategy pattern until I saw an article on it tonight. The benefits are that the code seems a lot simpler to read and the different code is split up very efficiently.
Of course you do need an if/case select somewhere to know which of the classes to create but the benefit is, it's in one place and attached to as little code as possible.
Anyway you have heard me ramble on about this topic for quite a while, this was the article I found which explained it very nicely, especially as the article/discussion isn't actually very long but then as I have blogged about before you should do the simplest thing that could possibly work
here is the link to the article that provoked this blog http://ootips.org/strategy-vs-case.html
I hope you found it as interesting as I did and please leave some comments on the subject as I'm sure you have guessed it's one that I enjoy waffling on about, probably without out that much insight (that's where you commenting on it help me out)
The benefit will come when you have to come and change the code again. Adding the strategy pattern allows you to really separate the code and dependencies. The main benefit of this is that when you have to add a new strategy or type then you can add it in and it doesn't effect the other classes because it is decoupled through the use of the interface or abstract class.
The one thing I would say is that I don't often see much code using large case statements, I find that people usually use big sprawling if statements.
Using a strategy pattern instead of a case statement I found is quite difficult to explain to people, it can be difficult to justify especially to programmers who don't know what the strategy pattern is (by name if not by logic). Initially it seems like you are needlessly creating etc classes to do what they could do by using an if or case statement. The problem I find with if statements is that they tend to grow and start sprawling in one method and then the same logic starts appearing in another method and the dependency on different classes grows, especially when you add a new case or if statement.
The real sign you should consider replacing those case/if statement is when adding one new type or if/case selection takes ages, ending with lots of similar changes.
If you are thinking or wanting to use the strategy pattern it can be added a lot easier when you are writing some new code or a new piece of code. I have used it recently and not just because I wanted to use the strategy pattern (put down that golden hammer) I did it without really remembering it was the strategy pattern until I saw an article on it tonight. The benefits are that the code seems a lot simpler to read and the different code is split up very efficiently.
Of course you do need an if/case select somewhere to know which of the classes to create but the benefit is, it's in one place and attached to as little code as possible.
Anyway you have heard me ramble on about this topic for quite a while, this was the article I found which explained it very nicely, especially as the article/discussion isn't actually very long but then as I have blogged about before you should do the simplest thing that could possibly work
here is the link to the article that provoked this blog http://ootips.org/strategy-vs-case.html
I hope you found it as interesting as I did and please leave some comments on the subject as I'm sure you have guessed it's one that I enjoy waffling on about, probably without out that much insight (that's where you commenting on it help me out)
posted by The Hosk at
11:58 pm
0 Comments:
Post a Comment
<< Home