When you use a Strategy pattern, you are now able to switch different implementations depending on the runtime environment or other domain logic.
But immediately you now have to worry - how to create the right strategy? Who will decide, who will create, where will the logic placed, what kind of configuration settings we will use, if any, or whether we will inject the strategy into the caller using dependency injection.
Hence, some of the following design patterns often come in mind, which when used along with the Strategy pattern makes a more complete solution:
Thinking of other patterns, in the light of a pattern is ofen lead by personal instincts, experience among other factors, but clearly having that ability seems extrememly valuable. These are different what GoF uses in their book, sort of related patterns. These are patterns that work in conjunction with the "base" pattern in question and are intended to serve as replacement of the base pattern.
Not only patterns, but it also makes you think of related refactorings that come in handy and preventing you from common pitfalls. Fowler and many others have made an impression of refactoring as applicable primarily to improve the design of "existing" code.
I, on the other hand them even in the design phase and often keep refactorings in the same toolbox as patterns, principles and practices. It makes me avoid making mistakes early on, that might need refactoring in the future. Hence, I think the term refactoring is sometimes, misleading. A more appropriate name would be just "Factoring".
No comments:
Post a Comment