Higher order object systems

One thing that's always surprised me when I read about the difficulties that people have with object orientation is that they think the design they want must be implemented within the object model of the language that they are using. If what you are doing is hard then it is entirely appropriate to build a higher order object system to use to implement it. It isn't even as if there aren't enough examples around. ActiveRecord is a very famous one, and the visitor pattern is another.

Functional programmers don't seem to suffer from this myopia. They happily write higher order functions that help them solve their problems in simple ways. Mostly when we're writing the object oriented parts of our software we forget how to do this. How often do you see custom message delivery, custom inheritance, custom method names or anything like it outside of framework code?

This failure to recognise higher order object oriented systems also manifests itself when looking at object oriented designs. We're happy with looking at high level designs for most things: a car has an engine; transmission; and some seats and wheels. When we look at a high level design in UML we get upset because the system sketch at the same level of abstraction doesn't show us how the steering wheel works through the suspension and we get even more upset because some idiot left the suspension out of the model altogether.