> 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 deciphe

> 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 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.