Is the Strategy Pattern based largely on the fact that there will be change to the software?
1) So in today’s environment, what if the change is total unknown and unforeseeable yet. At that point, will the Strategy Pattern be not appropriate to be added (at that moment)?
2) What if the Program Manager wants it done in 2 days, or ASAP or the faster you finish it, the better you look and the better the performance review. If you write it without using the Strategy Pattern, you may be able to finish within 2 days, otherwise, the PM may frown upon the delay and attribute it to bad performance. In that case, how do you balance the speed of implementation vs maintainability?
3) the same goes for programming under a contract job — for 2 months or 3 months. Won’t some programmer or the previous programmer on the job just ignore maintainability just so that it is done ASAP? Do the managers really care now that the project is 100% functional as spec’ed, whether it has the maintainability as well?
For 1), I recommend not to use Strategy Pattern. Overdesigning becomes very common these days, and provide little or negative impact to the maintainability itself. I have came across system which are designed to be easily extensible but in the end the extension never came to materialize.
Jeff Atwood have some suggestion on KISS and YAGNI.