• Post Reply Bookmark Topic Watch Topic
  • New Topic

static factory methods over constructors?  RSS feed

 
chad stevens
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello.
I have done some reading on this and some material say to consider static factory methods over constructors. Is this true in practice? I never saw an application using these. What should I be asking myself in order to be using these? They say that static factory methods unlike constructors, are not required to create a new object each time they say invoked, so how would this work then? They also say that unlike constructors, they can return an object of any subtype of their return type?? I am a little confused by what all this means and when we do define these, do we put them right after the constructor itself (it one is defined)?
Thanks.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
See http://c2.com/cgi/wiki?FactoryMethodPattern and linked pages for some discussion on this Design Pattern.
Personally, I think that the advice to favor one over the other is misleading - both approaches have their costs and benefits. Specifically, factory methods increase flexibility by reducing coupling, but also increase complexity by introducing another indirection and increasing code size.
So you will need find a good balance...
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
By way of illustration... one of the most far-reaching examples of this approach is the JCA (Java Cryptography Architecture).
Say you have a document with a message digest (essentially a secure checksum, like a glorified CRC) that you need to verify. With a bit of luck that digest would specify the algorithm that was used to calculate it. Let's say that the digest says the "MD5" algorithm was used.
You would ask the JCA to give you a MD5 implementation like so:Now MessageDigest is an abstract class; this call would return a MessageDigest subclass that implemented the requested algorithm. That's one thing you cannot do with the Java "new" operator: "new" always returns the class you ask for, it cannot return an appropriate subclass.
Also, I don't have to worry about the precise class that is implementing MD5 for me. In fact, the implementing class depends entirely on the JCA providers installed on the machine that runs the software; the implementation may come from Sun, from the Bouncy Castle boys, Cryptix, or your local intelligence operatives. You can't achieve that level of pluggability with "new" either. With "new", you have to know exactly what class you want.
The JCA (and JCE) contains abstract classes with static factory methods for all cryptographic objects (MessageDigest, Cipher, KeyPair, CertificateFactory -- lovely, a factory method that creates factories! -- you name 'em...).
Now a MessageDigest is stateful, so getInstance() will have to return a fresh object every time I call it. Had MessageDigest been stateless, then getInstance() could simply have given one and the same copy every time I called getInstance() (i.e. MessageDigest could be a Singleton). The beauty is, you and I as client programmers don't have to know about this or worry about this; we simply call getInstance() and rely on the implementation to implement the most appropriate creational pattern. With "new", you would have to be fully aware of creational issues.
There's all kinds of clever creational stuff that can be hiding behind getInstance(). What if creating a new MessageDigest was a very time-consuming task? The factory method could retain a soft reference to the objects it returns, prevent them from being garbage collected and recycle them instead. That way, fully transparently, it could implement an object pool. Once again, you and I as client programmers would not have to be aware of this at all. We just call getInstance(). If you'd use "new", you wouldn't be able to do any of this.
Does that help?
- Peter
[ January 17, 2003: Message edited by: Peter den Haan ]
 
Layne Lund
Ranch Hand
Posts: 3061
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by chad stevens:
Hello.
They also say that unlike constructors, they can return an object of any subtype of their return type?? I am a little confused by what all this means

It sounds like you need to study up on inheritence and polymorphism. These are key concepts that the Factory Method pattern uses. If you understand both of them, you will understand the statement above.
Layne
 
Maulin Vasavada
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi Peter,
excellent explanation!
i read the artical from the link Ilja posted but your post made me realize power of an "interface".
its so cool- u change business rules or underlying impl to achieve better/different set of behavior but ur client never knows!!
thanks
maulin.
 
chad stevens
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the explanation Peter, now I get the point!
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!