Win a copy of Terraform in Action this week in the Cloud forum!
  • 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:
  • Tim Cooke
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Jesse Silverman
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Al Hobbs
  • salvin francis

Abstract Factory, Factory

 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I've looked at Abstract Factory and Factory
design patterns in GoF but couldn't realize
the differences between them. I've read the
implementation also but my senses aren't helpfull
anyway
Bugra
 
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to the Ranch Bugra.
Abstract Factory creates several families of related objects. The different objects across the families implement the same interfaces, thus they can be used regardless the family they belong to.
Suppose a program is written to use GUI objects of different platforms: Windows, MAC etc. A button object implements an interface that allows the program to use it regardless the platform the program is running on. An abstract factory creates such buttons, windows etc depending on a specific platform at runtime.
Guidelines for implemention:
Define a superclass.
class abstract AbstractFactory {
abstract Button makeButton();
abstract Window makeWindow();
.
.
.
}
Each subclass will create a family of objects.
class WindowsFactory extends AbstractFactory {
Button makeButton() {
//create a button for Windows
}
.
.
.
}
Your program should find out which platform is running on and create the appropiate subclass of AbstractFactory.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
With other words, Abstract Factory is a combination of the Strategy pattern and the Factory Method pattern. Another possible application of the Factory Method would be to use it as a Template Method.
Did that help?
 
Bugra Cakir
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks, those rocks now I understand them !
 
Jose Botella
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
happy to hear that was helpful.
Another consideration:


Your program should find out which platform is running on and create the appropiate subclass of AbstractFactory.


This could be done in a static getInstance method in AbstractFactory. A singleton pattern is appropiate to obtain the subclass instance of AbstractFactory.
[ July 26, 2003: Message edited by: Jose Botella ]
 
Ranch Hand
Posts: 1376
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jose Botella:
Another consideration:
This could be done in a static getInstance method in AbstractFactory. A singleton pattern is appropiate to obtain the subclass instance of AbstractFactory.


Do you prefer using an actual factory object and instance methodsto using static methods? With the latter, you can have a static initialization method that determines the implementation characteristics; in its easiest form you could simply load a static implementation object with the appropriate condition-specific factory, and then the static methods would simply pass through to the implementation object.
This is only valid when you can never have two different abstract factories active in the same JVM, but that's exactly suited for platform dependence issues.
Just sort of thinking out loud.
Joe
 
Jose Botella
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Joe,
Do you mean something like this?
class MyApplication {
private static AbstractFactory factory;
static { /*initialize factory according to platform*/ }
static Button makeButton() { return factory.makeButton() }
static Window makeWindow() { return factory.makeWindow() }
.
.
.
}
interface AbstractFactory {
Button makeButton();
.
.
.
}
class WindowsFactory implements AbstractFactory { ... }
 
Joe Pluta
Ranch Hand
Posts: 1376
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes, that's exactly the idea, Jose!
 
Jose Botella
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Is there any advantage of the second approach?
I think the first one is clearer. You have a class and a purpose.
 
Joe Pluta
Ranch Hand
Posts: 1376
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think the major benefit is that it completely hides the implementation of the actual factory class. You don't even have a reference to it. In addition, you don't need a factory object in your code, you simply call the static methods. What do you think?
Joe
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm not comfortable with the code sample shown for static methods.
MyApplication implements all the methods on the AbstractFactory interface, but doesn't implement the interface, which is too much like Visual Basic's "polymorphism by coincidence."
It gives up the compiler's ability to check your code on MyApplication - imagine adding a method to the interface and fogetting to put it on MyApplication.
It's another opportunity for error- imagine MyApplication calling the wrong method on the real factory through a copy-paste error.
MyApplication is a factory that isn't acknowledged as a factory.
I'd prefer a factory-factory that gives you the correct one for the platform.

Other thoughts?
 
Jose Botella
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I dislike MyApplication. It has become less cohesive. Whatever its purpose is, now it has to deal with the creation of the factory object. As Stan pointed out, its interface has been polluted with the operations of AbstractFactory.
I think the first approach really encapsulates all the issues regarding the creation of objects from the factory, including a singleton access to the factory object. The class AbstractFactory is easy to understand, maintain and reuse.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic