aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes factory method pattern Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "factory method pattern" Watch "factory method pattern" New topic
Author

factory method pattern

long meng
Ranch Hand

Joined: Oct 10, 2008
Posts: 58
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:


SCJP 5.0 98%<br />SCWCD 5.0 in progress . . .
Hong Anderson
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
You can use creator.create(String type).


SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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?


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
long meng
Ranch Hand

Joined: Oct 10, 2008
Posts: 58
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
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
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:


[Edited code]
long meng
Ranch Hand

Joined: Oct 10, 2008
Posts: 58
so anyone tell me the advantages of factory method pattern, thanks
Jimmy Clark
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187


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
Ranch Hand

Joined: Oct 10, 2008
Posts: 58
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
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
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
Ranch Hand

Joined: Oct 10, 2008
Posts: 58
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
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187


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.


long meng
Ranch Hand

Joined: Oct 10, 2008
Posts: 58
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
Ranch Hand

Joined: Apr 16, 2008
Posts: 2187
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
Ranch Hand

Joined: Jul 05, 2005
Posts: 1936
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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: factory method pattern
 
Similar Threads
Doubt about EJBHome(design patterns)
Settling out which factory pattern EJBHome uses
Factory Classes
Factory Vs Abstract Factory Pattern
private constructor