> I don't see why it has anything to do with everything being an object.
Well it certainly blurs the lines, doesn't it? If you're returning an object anyway, it's not that much of a stretch to return a slightly different object depending on circumstances. Why does it warrant a pattern all to itself and an entire chapter of a book? And more to the point, why should I care about it, other than to try and decipher legacy ex-Java code like this?
To return slightly to the original point - where are the patterns for list comprehensions, decorators or generators? There aren't any, because in the Java/C++ world it's so hard to throw functions around like this. You need to look to fields like FP and Haskell to find good uses for list comprehensions beyond the very basic stuff.
> Why does it warrant a pattern all to itself and an entire chapter of a book? And more to the point, why should I care about it, other than to try and decipher legacy ex-Java code like this?
I think we started discussing different things. I wasn't saying the way GoF implements factory for C++, or the article in question does that, is useful; I mentioned elsewhere that copying patterns literally from Java/C++ isn't really fruitful when programming in Python http://news.ycombinator.com/item?id=3399581
Many of the classical design patterns will either be invisible or simpler in dynamic languages. In Peter Norwig's presentation, he claims 17 of the 23 are either invisible or much simpler for Dylan - we can make the same claim for Python, Perl, Ruby et al.
But even in Python, some patterns are non-obvious, and it's better that the developer knows them beforehand, rather than re-inventing them. Apart from the non-obvious ones, you sometimes need the others as they condense a paragraph of explanation to single term.
Factory isn't one of those non-obvious patterns - a competent developer, given the problem for the factory pattern(the above Image.open) will invent factory in under 5 minutes.
Well it certainly blurs the lines, doesn't it? If you're returning an object anyway, it's not that much of a stretch to return a slightly different object depending on circumstances. Why does it warrant a pattern all to itself and an entire chapter of a book? And more to the point, why should I care about it, other than to try and decipher legacy ex-Java code like this?
To return slightly to the original point - where are the patterns for list comprehensions, decorators or generators? There aren't any, because in the Java/C++ world it's so hard to throw functions around like this. You need to look to fields like FP and Haskell to find good uses for list comprehensions beyond the very basic stuff.