factory method pattern

[long meng]

i read about the factory method pattern, but i don't find out the advantages. when the system needs to add a new product, it'll add a new factory to create it, and the client will new a new factory class, what's the difference between this and new a new product directly?
for example, the client is like this:

   
public class Client{ 
        private Creator creator1,creator2; 
        private Product prod1,prod2; 
        public static void main(String[] args){ 
                creator1 = new ConcreteCreator1(); 
                proc1 = creator1.create(); 
                creator2 = new ConcreteCreator2(); 
                proc2 = creator2.create();         
                //if i need a product3, it will look like this:
                //creator3 = new ConcreteCreator3(); 
                //proc3  = creator3.create(); 
                //it will change the client code,is that obey the "open--closed" principle???
        } 
}     
 

[Hong Anderson]

You can use creator.create(String type).

[Ilja Preuss]

This looks to me like we are talking about Abstract Factory here, not Factory Method.

Anyway, the main reason to use an Abstract Factory is when you want to decouple the decision on *what* exactly to create, and *when* (or *how many* instances) to create.

So, typically, the client who calls the create method will *not* also instantiate the factory. The factory will be created outside and passed into the client (for example via Dependency Injection).

Does that help?

[long meng]

This looks to me like we are talking about Abstract Factory here, not Factory Method.

Anyway, the main reason to use an Abstract Factory is when you want to decouple the decision on *what* exactly to create, and *when* (or *how many* instances) to create.

So, typically, the client who calls the create method will *not* also instantiate the factory. The factory will be created outside and passed into the client (for example via Dependency Injection).

Does that help?

so the main() in the client should in another class, and the Client get everything(factory and product) ready, in the main(), just new a client, and call its method, is that right?

[Hong Anderson]

Ilja Preuss wrote:This looks to me like we are talking about Abstract Factory here, not Factory Method.

I don't think so. Abstract Factory is used for create "families" of product. It seems that many people don't understand Abstract Factory, "families" is a key.

Structure from GoF:

interface AbstractFactory {
   AbstractProductA createProductA();
   AbstractProductB createProductB();
}

ConcreteFactory1 implements AbstractFactory {
   ...
}

interface AbstractProductA {
}

ProductA1 implements AbstractProductA {
}

ProductA2 implements AbstractProductA {
}

interface AbstractProductB {
}

ProductB1 implements AbstractProductB {
}

ProductB2 implements AbstractProductB {
}

[Edited code]

[long meng]

so anyone tell me the advantages of factory method pattern, thanks

[Jimmy Clark]

public class Client{    
        private Creator creator1,creator2;    
        private Product prod1,prod2;    
        public static void main(String[] args){    
                creator1 = new ConcreteCreator1();    
                proc1 = creator1.create();    
                creator2 = new ConcreteCreator2();    
                proc2 = creator2.create();            
                //if i need a product3, it will look like this:   
                //creator3 = new ConcreteCreator3();    
                //proc3  = creator3.create();    
                //it will change the client code,is that obey the "open--closed" principle???   
        }    
}  

This is not a good example to demonstrate the benefits of the Factory Method design pattern.

To get a good unstanding of the benefits you will need to know a few other things like delegation, syntax-level dependencies, interfaces, low coupling, etc.

The primary benefit is that client objects should not have to be re-compiled and re-tested everytime a new class is created. The ultimate goal is extensibility and rapid development. A clear understanding of what these terms mean will also be required.

Good luck!

[long meng]

there is always a place to new the new factory, why i can't just new the new product instead of the new factory?

[Jimmy Clark]

You are missing the point of "not changing the client object code."

The classes of client objects which use the "factory method" do not need to be renamed, recompiled, newed or whatever.

Keep in mind that object-oriented design patterns are typically for solving significant issues with large systems. It might be hard to learn or understand if using "small" examples with only a few classes. If your implementation of Factory Method saves you time because you do not need to modify 20 to 50 classes, then this is a significant benefit.

[long meng]

James Clark wrote:You are missing the point of "not changing the client object code."

The classes of client objects which use the "factory method" do not need to be renamed, recompiled, newed or whatever.

Keep in mind that object-oriented design patterns are typically for solving significant issues with large systems. It might be hard to learn or understand if using "small" examples with only a few classes. If your implementation of Factory Method saves you time because you do not need to modify 20 to 50 classes, then this is a significant benefit.

i do remember the point, like my code: if there is a new product the Client class want to use , how to do it without change the code?

i'm realy confused, hope you can help me ! thank you very much!!!

[Jimmy Clark]

public final class SomeClientObject {

    ...
    public final int doSomeCalculationWithProduct() {
         ...
         Product _p = obj.getProduct(x);
         
         // do stuff here with Product object

         return y;       
    
    }
    ...

}

getProduct() is the factory method. The code that creates Product objects is in the class of 'obj'. The actual class name of the type of Product
does not exist in the client object. The call to "new" is not in the client object. The client object does not contain any syntax-level dependencies upon Product objects and you will not have to recompile the client object class if you change the name of the Product implementations or add new Product types.

The client object indicates which Product he/she wants using the variable x.

public interface Product {

}


public final class XYX implements Product {


}

public final class IntCLTR implements Product {


}

public final class Uredd implements Product {


}

public final class RanchIUY implements Product {


}

public final class SmilTREpl implements Product {


}

[long meng]

thanks James! i got it~!
and a little question here is where the SomeClientObject class get the factory object ?
shall i make it an instance varible, and use setter method to assign the concrete factory object to it?

[Jimmy Clark]

Great!

Experiment a little bit and try a few different ways. See which one you think is best and compare it to the others. This is an effective way to learn. There are no specific rules to implementing design patterns. You need to do it the best way for your application. When you have implemented a pattern three or four times, you will know what works well and what does not work well. Good luck!

[Hong Anderson]

long meng wrote:
and a little question here is where the SomeClientObject class get the factory object ?
shall i make it an instance varible, and use setter method to assign the concrete factory object to it?

For factory method pattern, don't call the creator "factory object", call it creator because it can have other responsibility.
When using Design Patterns, you should program to interface, Creator should be an interface (or at least an abstract class).
Client code will have dependency to interface, not concrete class.