| That is not entirely true. GoF patterns have tons of examples in Smalltalk, which is as dynamic as Ruby/Python. But they are more verbose and awkward to use in statically type languages, languages without first class functions (unlike Smalltalk, Ruby and Python), and methods like doesNotUnderstand, method_missing or __getattr__. And languages with mixins/metaprogramming support can do pretty much all patterns in a much better way (this is easy to see on the paper[1] where Gregor Kiczales implements the patterns in AspectJ and see how much simpler they become when you have mixins). The biggest problem with patterns is that people start with them, instead of refactoring to them when needed [2], which leads to a lot of over engineering (which is a form of premature optimization, and we all know what Knuth said about that). Uncle Bob (creator of Selenium, author of Clean Code) talked about it recently: http://cleancoder.posterous.com/patterns-of-reality [1] http://dl.acm.org/citation.cfm?id=582436 [2] http://www.industriallogic.com/xp/refactoring/ |
I would disagree that there are tons of Smalltalk examples there. There are in fact a few examples, and they actually don't weigh very much, because they are pretty small, and you don't really need the whole Design Patterns concept if you are a Smalltalk dude. I have a friend who first picked up the book after programming for 17 years in Smalltalk. He put it down after scanning through the first few chapters because it was very self-evident to him.
For young up-and-coming programmers, I recommend setting aside Design Patterns and reading everything you can find written by Peter Norvig. Start with his design patterns essay. The short version of which is that if you need design patterns, (in the sense of the book) then there is something lacking in your language. They are an unnecessarily.
I would never recommend Uncle Bob to anyone looking to improve programmming chops. Read Norvig instead. Uncle Bob came down on the wrong side of TDD and the fellow who failed to TDD his way into a sudoko solution. Peter Norvig comes up with a different notation, not a methodology, not a design pattern, and produced a very elegant solution.
So to improve your programming skills, avoid Uncle Bob, read Norvig, go easy on the methodology.