This week's book giveaway is in the OCMJEA forum.
We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Factory Method/Abstract Factory Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of OCM Java EE 6 Enterprise Architect Exam Guide this week in the OCMJEA forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Factory Method/Abstract Factory" Watch "Factory Method/Abstract Factory" New topic
Author

Factory Method/Abstract Factory

Paul Keohan
Ranch Hand

Joined: Mar 15, 2000
Posts: 411
I think I get the difference between these patterns. The difference in my mind is basically, the AF pattern is for when your client maye not even know the factory type. But the FM pattern implies one factory creating different objects.

What I don't get is why all the UML diagrams for the FM pattern show an abstract factory class - when we know what the factory is going to be.

Am I missing something?

Paul
Tulsi Rai
Ranch Hand

Joined: Jun 26, 2002
Posts: 55
Originally posted by Paul Keohan:
I think I get the difference between these patterns. The difference in my mind is basically, the AF pattern is for when your client maye not even know the factory type. But the FM pattern implies one factory creating different objects.
Paul



If i am not wrong, both AF and FM don't know the type of objects they are creating at runtime. this is my understanding based on what i read in the books but i can't show and prove how this (can't anticipate or don't know the type of class at run time) happens and gets resolved by AF and FM with examples. i would appreciate if some one could step in and show clearly these scenario with examples. Gosh.. i have never struggled so hard understanding anything than these AF and FM
thanks.
[ August 19, 2004: Message edited by: t ray ]
Paul Keohan
Ranch Hand

Joined: Mar 15, 2000
Posts: 411
Me too. And I'm finding it difficult to string my misunderstanding into a logical sentence.

When I see UML diagrams for the AF pattern, they often (but not always) have more than one concrete factory and more than one concrete product class to illustrate that there can be more than one extending from the abstract super class (orimplementing their interfaces). When I look at the FM pattern in UML it seems to be the same except there's only one concrete factory and one concrete product. I assume there can be many different concrete products extending from the abstract product. I would also assume there can be many different concrete factories extending from the abstract factory. So what is the difference between AF and FM?

Why does the FM pattern bother to show the factory as an interface or abstract class? - and isn't this makint it an AF pattern?

Paul
Paul Keohan
Ranch Hand

Joined: Mar 15, 2000
Posts: 411
Looking at the question from another angle:

See the sample code on this web page:

AF Pattern


Why not have the GUIFactory simply create the buttons depending on the OS type? - rather than creating factories (based on the OS type) to create the buttons? If it's simply a matter of readability, that's fine. But that doesn't explain the existence of the two patterns?
Nikhil Vasaikar
Ranch Hand

Joined: Aug 18, 2004
Posts: 56
I think an Abstract Factory returns family of similar objects and a Factory choses between two different objects (implementation)

You may refer to the code below, which has Factory as well as Abstract Factory implemented. Singleton is also used for Concrete Factories


The output
Run 1:-
Look And Feel - Windows
This is a Windows Button
This is a Windows Scrollbar

Run2:-
Look And Feel - Unix
Unix OS not defined in our System

Run3:-
Look And Feel - Motif
This is a Motif Button
This is a Motif Scrollbar

[ August 20, 2004: Message edited by: Nikhil Vasaikar ]
[ August 20, 2004: Message edited by: Nikhil Vasaikar ]
Sujatha Kumar
Ranch Hand

Joined: Jan 05, 2004
Posts: 134
Nikil,

That was an excellent example.

Infact I understood what i have read in the books.

I really appreciate your posting.


SCJP,SCWCD,SCBCD,SCEA Part I
Paul Keohan
Ranch Hand

Joined: Mar 15, 2000
Posts: 411
Thanks Nikil. Very helpful!
Sujatha Kumar
Ranch Hand

Joined: Jan 05, 2004
Posts: 134
Hi Nikil,

Following is the description given for a Abstract Facotry Pattern in SCEA guide

[BOLD]
"The Abstract Factory pattern provides an abstract class that determines the appropriate concrete class to instantiate to create a set of concrete products that implement a standard interface"
[/BOLD]


In the example you have provided no abstract classes has been provided
rather a Singleton (MotifFactory /WindowFactory) is provided.

Is it ok??

Kindly Clarify,
Your Clarifications are appreicated

Regards
Nikhil Vasaikar
Ranch Hand

Joined: Aug 18, 2004
Posts: 56
Hi Sujatha,

The interface AbstractComponents is the abstraction i.e the Abstract Factory, and the Singletons are Concrete Factories of this abstraction. I have used interface as there is nothing common to both the Concrete Factories. If you have anything in common you could probably use an Abstract class instead of the interface AbstractComponents and have the implementation of commonalities in this Abstract Class, so it becomes available to both the Concrete Factories. I hope this explains what I understand by Abstract Factory. I suggest you also refer to the Class Diagram given in the GOF Book.
Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1871
Hi Nikhil

good examples. I have something to add.

You know I have endedup using something which I would like to explain using your code samples. You have the, interface AbstractComponents ...now,

instead of that I created abstract class AbstractComponents like,



you see what I am doing? In actual code I use, I read the "componentName" classname from a configuration file. So as a result my code is completely independent of the actual classes and I we change one entry in the config file the "whole" factories/objects returned from factory changes

The only issue is I am following logical convention to have "getInstance" method name in each of the child AbstractComponent factory but I thought it was reasonable given the flexibility it gives me..

Please provide your thoughts on this.

Here, my confusion while designing this was "what is AbstractFactory and what is Factory Method"...But I have come to the following conclusion,
1. My AbstractComponent is AF
2. AF's impl - MotifAbstractComponent is FM but I force it to impl methods of returning specified objects via parent AF...

People, please feel free to provide your thoughts here..

Regards,
Maulin
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Factory Method/Abstract Factory