I had similar thoughts but from the other direction - yes, this is what Ruby (and/or Rails particularly) seemed to want to avoid. "We don't need all of these cl

I had similar thoughts but from the other direction - yes, this is what Ruby (and/or Rails particularly) seemed to want to avoid. "We don't need all of these classes, look how simple this is! It's not like Java with all of these patterns, etc." But actually I don't think there's much wrong with this. It is OO. It's not domain object oriented, it's just OO. you're creating an object which has a single responsibility - to calculate a sort order, or to take something and present it. While GoF disciples may well have made many mistakes, this doesn't mean that this kind of OO design which emphasizes separation of concerns is wrong. It may look more complex, and perhaps it's a premature refactoring - we don't know out of context. But these classes are doing more than "just wrapping" something. They're promoting the concept of "displaying" or "sorting" or "calculating a rate for something" to a first class concept in your system, and in the process making it easier to change the implementation and to test in isolation. They're not from the problem domain. But they make sense in your program domain. And that's fine (if not abused). Edit: (as sibling reminded me of a point to make). Some of these classes could be functions if your language supports that. But they don't have to be, if making them classes makes them easier to work with, test and understand.