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.
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 ]
Joined: Mar 15, 2000
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?
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?
Infact I understood what i have read in the books.
I really appreciate your posting.
SCJP,SCWCD,SCBCD,SCEA Part I
Joined: Mar 15, 2000
Thanks Nikil. Very helpful!
Joined: Jan 05, 2004
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
Joined: Aug 18, 2004
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.
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..