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?
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.
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.
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.
pie. tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop