• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Factory Method/Abstract Factory

 
Ranch Hand
Posts: 411
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 411
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 411
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Ranch Hand
Posts: 56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Nikil,

That was an excellent example.

Infact I understood what i have read in the books.

I really appreciate your posting.
 
Paul Keohan
Ranch Hand
Posts: 411
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Nikil. Very helpful!
 
Sujatha Kumar
Ranch Hand
Posts: 134
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 56
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic