aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Static Factory Method Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Static Factory Method" Watch "Static Factory Method" New topic
Author

Static Factory Method

Kevin Lillybridge
Greenhorn

Joined: Mar 06, 2008
Posts: 8
Hello,

Im creating a dialog box where I would like to use a static factory method as opposed to a public constructor. Without the static factory method I need to use two constructors because I need to use two different objects that I will display in the dialog. If I were to use a static factory method is it recommended to use two static factory methods, one for each different object, and set both constructors to private?

Thanks for the Help.
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Originally posted by Kevin Lillybridge:
I'm creating a dialog box where I would like to use a static factory method as opposed to a public constructor.


Now this sounds like it is straight out of Effective Java: "Item 1: Consider providing static Factory methods instead of constructors". (Version for the 2nd Edition: Chapter 2: Creating and Destroying Objects)

The advantages listed are:
  • static factory methods can have meaningful names
  • static factory methods don't have to return new objects.
  • static factory methods can return subtypes.


  • The greatest advantage is that it can return subtypes. However this refactoring seems to suggest "I need looser coupling". Towards that objective very little progress has been made. You are replacing concrete constructors (making you dependent on the concrete classes) with static methods on a concrete class (making you directly dependent on the concrete class implementing the static factory methods and the interfaces returned by the static methods - the point is that you are still "dependent on implementations, not just interfaces". To drive this to its logical conclusion you should really go further:
  • You already have class A and B.
  • Now create interface I and J and let class A and B implement them.
  • Create an interface K that has getI(args) and getJ(args) methods on it.
  • Create a class F that implements K and creates class A instances in getI(args) and creates class B instances in getJ(args).
  • Modify your dialog box so that you can (dependency) inject a class that implements K either in the dialog box constructor or through a mutator (setter) method.
  • Now your dialog box can use the instance that implements K to obtain instances that implement I or J. So the dialog box now depends on interfaces I,J,K, not classes A,B,F. The dialog box code is now truly "programming to interface and not to implementation"


  • Your coupling has now been loosened - but with it comes with some increase in complexity so you need to be sure that your gain outweighs the cost before you apply this. However this technique has been heavily favored since developers have been using unit test frameworks like JUnit because it gives them flexibility to "inject" instrumented mock versions of the classes for the purpose of unit testing.

    Micheal Feathers: The Humble Dialog Box (PDF)
    Daniel Gartner: Writing More Testable Code with Dependency Injection
    Martin Fowler: Inversion of Control Containers and the Dependency Injection pattern
    [ May 13, 2008: Message edited by: Peer Reynders ]
    Kevin Lillybridge
    Greenhorn

    Joined: Mar 06, 2008
    Posts: 8
    Thanks for the help.

    Yes, this is exactly from Effective Java. I picked up the book at JavaOne and trying to work some of the tips into my old code.

    I think the best solution will be for me to subclass my Dialog box and use static factory methods for each of the subclasses.

    Thanks again.

    -Kevin
    Peer Reynders
    Bartender

    Joined: Aug 19, 2005
    Posts: 2922
        
        5
    Originally posted by Kevin Lillybridge:
    use static factory methods for each of the subclasses


    But what do you gain?



    versus



    In both cases you are still dependent on the implementation of A! The static method only gives you the freedom to choose a more meaningful name and you could turn it into a Singleton ( shudder).


    Also, why are you sub classing the Dialog box? Are you using it polymorphically? For reuse it is often preferable to favor object composition over class inheritance..

    Swing best practice: inheritance vs. composition
    Kevin Lillybridge
    Greenhorn

    Joined: Mar 06, 2008
    Posts: 8
    Well, the static factory method would make it easier for naming and keep my constructor private. I like the multiple interface idea but seems a bit unessecary and complicated for what im doing.

    The only reason I'm subclassing is because I need the exact same look and feel for my dialog but the functionality of the dialog will be totally different. For example, my dialog box is basically a collision resolver. Depending on what class generated the collision, class A or class B, will require me to render text differently, save to different servers, change icon and dialog title, and change editable state of some of the text boxes that allow you resolve the collision. There is also the possibility of creating more of these collision/dialogs that will again need seperate functionality from the other dialogs.

    If i create abstract methods to set my various functionality then each of the subclasses will be required to implement the methods and future developers could write what they need based upon whatever theyre working.

    Sound like im on the right track?
    Kevin Lillybridge
    Greenhorn

    Joined: Mar 06, 2008
    Posts: 8
    I think I should probably read the chapter on Inheritance vs. Composition before I get ahead of myself!
    Nicholas Jordan
    Ranch Hand

    Joined: Sep 17, 2006
    Posts: 1282
    Ijust got some Crypto to useable development, that was a critical breakover for the thinking about actually letting someone have a copy. Eventually, after wrestling with supertype() throws and, uh,... several other impedence mismatches - I tried the static getInstance(...) that I found the crypto libs using. Skeptical, I went to that within a few days to get instances.

    I was able to split apart the typeA ( && / || ) typeB in the static factory method. I had not been able to do that before. I also have init() methods in first prototype of most classes, including small utility file scope classes. Maybe they are only stubbs. I put the static factory getInstance() there as a stubb and found that it can replace init() by providing a uniform implementation to start with. Generating cryptographic decent keys, along with where to put them and so on, can still be a functionality of the returned object.

    If one is on a team, I suggest using the interface idea and only exposing the interfaces so that shop decisions are specified for Team Lead or whomever is Authority on the matter.
     
    Don't get me started about those stupid light bulbs.
     
    subject: Static Factory Method