11–20 of 20 posts
> This book is about learning design patterns through the medium of Python language.
Its a book about learning the patterns, not idiomatic (or even good) Python. As a example of idiomatic and good python, this book is useless, but if you just want to understand how patterns are used in other languages, this book is not bad.
For everyone saying if you really need these patterns. From the site header > This book is about learning design patterns through the medium of Python language. Its a book about learning the patterns, not idiomatic (or even good) Python. As a example of idiomatic and good python, this book is useless, but if you just want to understand how patterns are used in other languages, this book is not bad.
For instance, go and have a look at the example code for his command pattern: http://dpip.testingperspective.com/?p=22 That's not idiomatic anything - in normal Python you'd probably expose a couple of methods on the Light (on/off) and construct a switch to call those. Two classes, duck typed and no need for Command abstract classes and all the extra boilerplate.
Do we really need factory pattern in Python? I mean with all those dynamic calling methods? I'd like to see more patterns with decorators, list comprehension, map/filter chain and yield.
> Do we really need factory pattern in Python? Yes. from PIL import Image im = Image.open("bride.jpg") Image.open here is a factory, and im will be an object of a different class, depending on the filename you pass to it(jpeg, gif, png). That is just one example, but you get the idea.
In this particularly case Image isn't a class, and Image.open isn't a method: https://bitbucket.org/effbot/pil-117/src/162542cc8aca/PIL/Im...
I don't know that there's any equivalent for this in Java, so I think the grandparent's question still stands.
Earlier quoted context omitted.
> Do we really need factory pattern in Python? Yes. from PIL import Image im = Image.open("bride.jpg") Image.open here is a factory, and im will be an object of a different class, depending on the filename you pass to it(jpeg, gif, png). That is just one example, but you get the idea.
Well really, what's the point in calling it a factory? In Ruby or Python everything is an object, every method or function call returns an object, hence everything is a factory, and the term loses its meaning. In this particularly case Image isn't a class, and Image.open isn't a method: https://bitbucket.org/effbot/pil-117/src/162542cc8aca/PIL/Im... I don't know that there's any equivalent for this in Java, so I thin…
I don't think factory is defined as anything that returns an object.
I am not a design pattern buff, but here is what the wiki entry says:
* it deals with the problem of creating objects (products) without specifying the exact class of object that will be created. *
I don't see why it has anything to do with everything being an object.
The Image.open example is factory pattern. It isn't implemented the same way it's implemented for Java/C++, and I wasn't commenting on the implementation; but that doesn't make it not factory.
Similarly, the command pattern, in a language with first-class functions and closures, will be implicit and look nothing like the one implemented in GoF book.
If you are taking the implementation in GoF as the definition, callbacks as we do in Ruby, JS, Python et al. look nothing like command pattern. But the implementation isn't definition, and GoF explicitly mentions it that these patterns aren't the same in all languages.
Also, what is the controller doing? Why is there even a DefectModel with database code in it? Why is it not using an ORM style like every other database-fetching thing written this century?
I've looked at a couple of "chapters" of their "book" now, and it's all hideous train wreck code like this, with stuff that reads like it's been cut+pasted out of a wiki somewhere, and no sample output/data. I'm not sure what you're supposed to learn from these examples, other than "Design Patterns are hard".
Earlier quoted context omitted.
Well really, what's the point in calling it a factory? In Ruby or Python everything is an object, every method or function call returns an object, hence everything is a factory, and the term loses its meaning. In this particularly case Image isn't a class, and Image.open isn't a method: https://bitbucket.org/effbot/pil-117/src/162542cc8aca/PIL/Im... I don't know that there's any equivalent for this in Java, so I thin…
> In Ruby or Python everything is an object, every method or function call returns an object, hence everything is a factory, and the term loses its meaning. I don't think factory is defined as anything that returns an object. I am not a design pattern buff, but here is what the wiki entry says: * it deals with the problem of creating objects (products) without specifying the exact class of object that will be created…
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.
Earlier quoted context omitted.
> In Ruby or Python everything is an object, every method or function call returns an object, hence everything is a factory, and the term loses its meaning. I don't think factory is defined as anything that returns an object. I am not a design pattern buff, but here is what the wiki entry says: * it deals with the problem of creating objects (products) without specifying the exact class of object that will be created…
> 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 legac…
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.
Earlier quoted context omitted.
> 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 legac…
> 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 r…
Do we really need factory pattern in Python? I mean with all those dynamic calling methods? I'd like to see more patterns with decorators, list comprehension, map/filter chain and yield.
> Do we really need factory pattern in Python? Yes. from PIL import Image im = Image.open("bride.jpg") Image.open here is a factory, and im will be an object of a different class, depending on the filename you pass to it(jpeg, gif, png). That is just one example, but you get the idea.
PIL.open = lambda filename: PIL.getattr("open_" + filename.split('.')[-1].strip())
PIL.open('whatever.jpg') == PIL.open_jpg('whatever.jpg')
Factory pattern is basically a huge pile of lookup table of if's and switch's, unless you use some clever voodoo in reflection, it's just a bridge to map semantic vars to memory/VM addresses.
Which in a way, is a user-level re-implementation of a dynamic language engine (poor man's version)