3 ms·

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 everyth

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/Image.py#cl-1943 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.

irahul 15y ago
> 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. 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.
- anthonyb 15y ago
  > 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.
  - irahul 15y ago
    > 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.
    - anthonyb 15y ago
      So, I'm curious - which patterns do you consider non-obvious in Python?

irahul 15y ago

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

anthonyb 15y ago
> 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.
- irahul 15y ago
  > 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.
  - anthonyb 15y ago
    So, I'm curious - which patterns do you consider non-obvious in Python?