| Some problems are better expressed in paradigms other than OOP. One of the beautiful things about Ruby is that you can use OOP or other paradigms on a case-by-case basis in accordance with what's best for the problem at hand. This article seems to miss the elegance of that. Design patterns and OOP have their place, but this article adheres to them too dogmatically for my taste. It reminds me a little of this: http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom... When I first started programming, I wanted a set of rules which, if followed strictly, would always guide me towards the perfect architecture. I've since learned that such a set of rules doesn't exist. Instead, we have to rely on our experience and insight to tell us which architecture will solve a given problem elegantly, and which will shoot us in the foot. The OOP absolutists seem to be looking for that same El Dorado I once wanted. Ostensibly, design patterns promise us programming bliss through tried-and-true, universally applicable architectures. But they don't. Oftentimes, they just give you more lines of code than you really need. It sounds like I'm dumping on OOP and design patterns, but I'm not. Like I said, there are plenty of perfectly good applications for them. My point is that it takes a bit of that aforementioned experience and insight to recognize those instances when they're appropriate. Otherwise you're just painting by numbers. |