Hacker News Reader

Hacker News

Comment by globalrev | Hacker News Reader

Parent Full thread

globalrev

you cant in java!?

View on HN

Of course you can.

I don't see how passing around classes could replace the factory pattern?

In Java these days usually Spring is the factory...

Usually you use the factory pattern because you want to customize the concrete type of object that's instantiated, correct? In Python, you'd just pass the class itself in, and since every class is a callable that constructs an instance of itself when called, you can use that to control instantiation:

   class Foo: ...
   class Bar: ...
   def factory_client(cls):
      my_instance = cls()
      ...
      return my_instance

   foo_instance = factory_client(Foo)
   bar_instance = factory_client(Bar)

You can do the same thing in Java with Class objects and reflection (Class.newInstance() etc.), but reflection is a.) slow and b.) clunky, so most Java programmers create factories instead. Parameterized classes are much more a part of Python culture than Java culture.

Well thinking about Spring, it does a lot of wiring behind the scenes. How would you do that with Python? What does the factory_client method do?

I don't think Java Reflection is a/the problem.

factory_client does whatever you want it to do - it's just the method that would call your Abstract Factory or Factory Method or whatever.

I've never used Spring, but I assume that the wiring it does is similar to JSF managed beans, eg. you give it an XML config file and it takes care of creating the appropriate Java objects from that. As for how you'd do it in Python - you wouldn't. To quote Phillip Eby: "XML is not the answer. It is not even the question."

http://dirtsimple.org/2004/12/python-is-not-java.html

That's because XML is usually easier to write than Java but harder to write than Python, so you're better off just writing the Python.

You'd write your classes, and then stick them in a data structure somewhere. You could even use the package structure of your app as that data structure - have the client code receive a module (modules and packages are first-class in Python), then use getattr to pull out the class object. Then when you have a class object, you call it to create a new instance.

I suppose if you want some security guarantees, you'd explicitly specify the classes that may be passed in to the method. For example, in my own app, I have a bunch of classes that essentially represent language constructs in a visual domain-specific language, each of which has a "default" value so that when the user's clicking away they don't have to type in code from scratch. I wanted to expose these defaults to JavaScript, the language of the UI. So I put together a dictionary of the classes that I want exposed, then loop through it, instantiate each class as the default, encode each object as a plain old dictionary (they all have a 'props' method that returns the object represented as a JSON-suitable dictionary), and JSON-encode the whole mess. It totals like 5 lines for the whole thing, not counting the list of classes to be exposed.

Yeah, that's exactly what I meant. I sometimes see people create an entire class wrapping a single factory method, and then override that method in various subclasses to construct different types of objects. The class, the subclasses, and the factory methods are all redundant in Python. The Twisted framework is an offender that comes to mind.

I haven't worked in Java very much, so I'm not sure what the trade-offs are with using reflection vs. factory methods. But GoF gave examples in C++, and was published in 1994, before the reflection API was released with JDK 1.1 in I think 1997. It's entirely possible that using factory methods to customize the concrete types of objects doesn't make a lot of sense in Java, either.

Reply on news.ycombinator.com