Discussing Design Patterns - Factory Method & Abstract Factory pattern

Hi All,
With help of Carl Trusiak and JUNILU LACAR I am starting this first thread regarding design patterns. This thread is one of the thread in the series of threads which I will be starting to discuss about the design and use of the patterns. I would like to start only two threads in a week, so that people get sufficent time to post their arguments.
Like many of us I will be a spectator most of the time because Iam also in course of studying and understanding the design patterns.
As suggested by Junilu, we will be studying the patterns in the order in which it is suggested in http://www.industriallogic.com/papers/learning.html
I think what most people will be looking for will be the following.
1. If possible, what does the particular design pattern does? (But it is assumed that people have atleast read GoF book)
2. Where did u use the particular design pattern.
3. Why did u thought of using the particular design pattern?
4. How did u implemented the particular pattern. If possible, with help of the code.
Lastly I would request the people who have already use the design patterns in their project to come forward and please try to keep this thing going.
---------------------------------------------------------------
This first thread is for Factory Method & Abstract Fatcory Pattern

I would expect participants of this discussion to have at least some idea about Factory pattern. If you do not have the GoF book, use your favorite search engine (I'm partial to Google) and search for "Factory design pattern".
Some opening questions/points of discussion:
From the learning guide: How does Factory Method promote loosely coupled code?
So now that you know what the Factory does, can you think of any real-world examples where it can be applied?
Can you identify any classes in the standard Java library that follow the Factory pattern?
Patterns are not created, they are discovered. Try to look at some your code or designs and see if you can find the Factory pattern in it.
Give some examples of designs that would benefit from being refactored into a Factory pattern.
A pattern that is applied inappropriately can become an AntiPattern. Studying antipatterns can be as beneficial as studying patterns. Can you think of situations where applying the Factory pattern is a bad idea?

[This message has been edited by JUNILU LACAR (edited June 11, 2001).]

Great idea, this will be useful to a lot of us. I have just started the GoF book and looking forward to the discussion on this thread

You can certainly see an excellent example of the Factory approach in Sun's JAXP package for XML parsers. JAXP does not actually contain a parser - it provides for creating and configuring a parser according to your requirements.
The factory classes are SAXParserFactory and DocumentBuilderFactory
Bill

I desparetly need to understand How an AbstractFactory is implemented using prototypes.
pl. give me code samples.

Hi,
Can you identify any classes in the standard Java library that follow the Factory pattern?
The Home Interface (EJBHome) is a Factory for the Remote Object (EJBRemote).The Home Object locates the the Remote Object which may be located on the same machine or any machine over the network by using JNDI and creates the instance of Remote Object.
How does Factory Method promote loosely coupled code?
Factory Pattern is based on Indirection.In the above example, the Home Object acts as an indirection and see to it that RemoteObject is not coupled with the JNDI service.
Am sorry for short answers.Can't help it now - am busy with preparation for Test 486.

Will come up with detailed description/code by this week-end.
BTW, we can discuss about the Motivation behind Factory Pattern also.Also,the AntiPattern issue which Junilu raised seems very interesting.

Thanks,
Sandeep
[This message has been edited by Desai Sandeep (edited June 12, 2001).]

What fun! A new game

.
Let's see. I THINK that this would be an example of an implementation of the Factory pattern.
Once upon a time MicroSoft (yes, I DARE say the name) developed a tool called Access. Then it developed MSWord and Excel. However since each tool was developed by a different group of programmers the user interfaces did not resemble each other much. How irritating to go into Access and find Delete under File, and then go into Excel and have to poke around until you found Delete under Edit (or whatever).
So when it came time to bundle these fine tools up into MSOffice the decision was made to refactor and abstract the applications into a generic MSApplication of which Excel is a subclass. Then a generic MSMenuBar was created with all the standard stuff, and an ExcelMenuBar subclass was created by Excel thus promoting the "common look and feel" across the tools.
Of course they did it in Visual Basic, but I think that the pattern still applies.