I'm not a big fan of design patterns. But the argument presented here is really weak. For instance: > Since no situation in code is ever the same, the only way

I'm not a big fan of design patterns. But the argument presented here is really weak. For instance: > Since no situation in code is ever the same, the only way to see if a design pattern works for a code base is to try it. Or you could think hard for a minute and predict whether it will work. I get good results with that. > Refactoring code to a new structure is a significant time investment. However, everyone needs to make time compromises. Especially in software, where customers are won primarily by being the first on the market. So after the second or maybe third attempt to fit our code into a design pattern, we settle, usually for the last attempt. That is far from a rigorous analysis of which of all the available design patterns actually makes our code simpler. Sure, if you need to try every tool in the toolbox you'll have a bad time. A carpentry theorist could argue, since you can't truly know which tool is best, you need to try pounding in a nail with a screwdriver, with a wrench, with a hacksaw, with a voltmeter, etc. But this isn't a problem for actual carpenters.