Something I'm working on stores Procs in objects a lot. I started out using a dispatch table and then realized I'd have a much cleaner system if I encapsulated the dispatch table within an object. Then I realized the object would need two additional dispatch tables, and created a Struct to store them in, and gave the object the Struct. (The additional dispatch tables were very closely related in theme and the variable names were just infinitely cleaner that way.)
At this point the fact that I'm using dispatch tables is a lot less obvious. Further refactorings will probably emphasize this effect. There's a question here: when does a set of dispatch tables encapsulated for convenience within objects become a Strategy pattern?
The Rails community is notoriously disrespectful of its competitors, and because of this there's a great deal of people who scorn design patterns as a relic of Java's pre-Ruby Jurassic Age. The alternative point of view is that design patterns are some of the valuable discoveries of the object-oriented avenue of investigation. My interest in dispatch tables comes from the Lisp world via Perl, but the fact that it ends up in design patterns territory seems to validate the whole concept of design patterns to some degree.