• 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
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Abstract Factory and Factory Method

 
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Folks,
Could anyone please give me some real-world experiences and insights into situation where each one of these patterns are required or advisable? It would be really great help if you could also explain situations using these methods and without them. I read them in the pattern book but had hard time to relate as I don't have any real world situation that I have come across Where I have been required to use them to address the problems.
thanks.
[ July 02, 2004: Message edited by: Tulsi Rai ]
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Factory patterns in general are good for decoupling classes from each other.

Consider this example:

The problem here might be that you don't want to couple Client to the particular implementation of the service, Service. You can decouple the two by introducing an indirection in the form of an interface and a factory:
 
Tulsi Rai
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Lasse,
Thank you for your explanation. is this example for Abstract Factory or Factory Method? Also, what good the decouple does? we are basically having other class to give us an object. I would appreciate if you could provide some explanation that would reinforce my understanding. thanks.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Tulsi Rai:
is this example for Abstract Factory or Factory Method?


Factory Method.

Originally posted by Tulsi Rai:
Also, what good the decouple does?


It abstracts the implementation of the service from the user of that service. The benefits are the benefits of indirection in general -- more flexibility. For example, by not having the client code use "new Service()" directly, you are able to substitute a mock implementation at runtime in your unit tests.
 
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 Tulsi

See the very recent post in this same forum at - here

See if it helps.

Regards
Maulin
 
Ranch Hand
Posts: 374
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A couple good real-world examples are

a) connection pools : If there is no object available, it will create one and return it to the caller. If there is one available, it will return that one. This obviously results in better performance as you don't constantly create and throw away objects or open and close connections.

b) caches : See above; a connection pool is simply a special type of cache. So you could consider a cache an abstract factory, and a connection pool an extension of it into an actual factory.

c) lookups : In several of my real-world applications, I have to do searches based on different criteria. One of my parameters is, say, searchType. I pass the LookupFactory the value of the searchType and it returns me a Lookup, which is an interface that defines a method to load a data bean.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Tulsi, I noticed you have changed your display name into something that doesn't comply with our naming policy -- please edit it again into something compliant (with a separate first and last names). Thanks.
 
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
A more useful example would be a situation where the actual class to be returned is not known to the class that needs the object.
All it knows is that it wants a Service with a name, but doesn't care (and probably can't even know because the Service is defined elsewhere) what the exact class is.

An example is the following code I use in a large project:



handlers looks up the class to be instantiated based on a string passed which contains a descriptive name for it (similar to JNDI but simpler as no remote retrieval is needed).
The method creates an object derived from AbstractHandler from that classname, and calls its initialisation method with the rest of the parameters before returning it.
The factory is implemented as a Singleton which is typical for factories.
 
Ranch Hand
Posts: 1419
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Does anyone else feel that "Abstract Factory" is poorly named?

It seems to me that the only difference between "Factory" and "Abstract Factory" is whether it builds a single kind of object ("Factory") versus a family of related objects ("Abstract Factory").

If that is the difference, then a "Factory" is in no way any less abstract than an "Abstract Factory," and the latter might have been better named "Family of Products Factory."

Comments?
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As far as I can tell, "Factory" is just a short hand for the original "Abstract Factory" pattern.
 
Frank Silbermann
Ranch Hand
Posts: 1419
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
As far as I can tell, "Factory" is just a short hand for the original "Abstract Factory" pattern.



No, the Gang of Four book lists them as two separate patterns. And the only difference, as far as I can tell, is whether the factory produces a family of related products, or just one type of object.

No difference in abstractness, as far as I can see.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Frank Silbermann:
No, the Gang of Four book lists them as two separate patterns.



I am quite sure that there is no "Factory" pattern in the GoF book. Perhaps you are confusing it with "Factory Method"?
 
Frank Silbermann
Ranch Hand
Posts: 1419
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Ilja Preuss:
As far as I can tell, "Factory" is just a short hand for the original "Abstract Factory" pattern.



Originally posted by Ilja Preuss:


I am quite sure that there is no "Factory" pattern in the GoF book. Perhaps you are confusing it with "Factory Method"?



I always assumed "Factory" was short hand for the original "Factory Method" pattern. I suspect that I would not have been confused if those two patterns had been given more informative names, e.g. "Factory" and "Multi-factory."

"Factory Method" is no less abstract than "Abstract Factory" -- and "Abstract Factory" is no less methodical than "Factory Method."

Does anyone else find these names confusing?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Frank Silbermann:
I always assumed "Factory" was short hand for the original "Factory Method" pattern.



My impressions is that the use of the term "Factory" is quite inconsistent in the community...


"Factory Method" is no less abstract than "Abstract Factory" -- and "Abstract Factory" is no less methodical than "Factory Method."



With Abstract Factory, you have a whole object whichs sole responsibility is to create objects. It is a specialized form of the Strategy pattern.

A Factory Method is just an internal part of a bigger object. The responsibility of that object is not to create things, it just makes use of the Factory Method to do whatever it is supposed to do. It's a specialized form of the Template Method pattern.

I actually think that the names do make some sense...
 
Jeroen Wenting
Ranch Hand
Posts: 5093
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
and me always thinking an abstract factory was a system to create factories in the same way a factory creates other things.
Kinda a meta-factory.

Guess I was wrong

Looking it up in Grand (Patterns In Java Volume 1 page 99) gives:
"Given a set of related abstract classes, the Abstract Factory pattern provides a way to create instances of those abstract classes from a matches set of concrete subclasses".

Factory pattern:
"You organise this class so that it can instantiate other classes without being dependent on any of the classes it instantiates".

So an abstract factory is a factory that creates instances of concrete classes derived from abstract classes while a factory creates instances of concrete classes which aren't necessarilly based on anything???
 
Frank Silbermann
Ranch Hand
Posts: 1419
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Jeroen Wenting:

Looking it up in Grand (Patterns In Java Volume 1 page 99) gives:
"Given a set of related abstract classes, the Abstract Factory pattern provides a way to create instances of those abstract classes from a matches set of concrete subclasses".

Factory pattern:
"You organise this class so that it can instantiate other classes without being dependent on any of the classes it instantiates".

So an abstract factory is a factory that creates instances of concrete classes derived from abstract classes while a factory creates instances of concrete classes which aren't necessarilly based on anything???



What you quoted from Grand does indeed sound consistent with the names of the patterns, giving Abstract Factory a degree of abstraction not assumed in Factory Method.

However, from http://www.patterndepot.com/put/8/Creational_Patterns.htm (a site I'm told provides Java examples of GoF patterns) I read:


The Factory Method provides a simple decision making class which returns one of several possible subclasses of an abstract base class depending on data it is provided. (emphasis added)

The Abstract Factory Method provides an interface to create and return one of several families of related objects.



Notice that the word abstract is used in the Factory Method definition -- but not in the Abstract Factory definition! Trying to follow a patterns discussion with names like this is like trying to read a computer program that names its variables X1, X2, X3, ....

These latter definitions seem consistent with the GoF definitions, but different from the definitions you cite from Grand. When the various authors of patterns books use the same terms inconsistently, that only adds to the confusion.
 
Ranch Hand
Posts: 37
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The Grand book is notoriously flawed. Not a good reference. The GoF is the bible and I would recommend you to pick up the companion java book "Design Patterns Java Workbook" by Metsker for a good detailed view on the GoF patterns. Things became much clearer for me after I spent Summer 2002 going thru the exercises in that book.

And yes: names are consistent if you understand precisely what the goal is for these two patterns: As for Factory method, it can either be in its own class (append a Factory postfix to the class) or inside another class (usually the method is named create) depending how complex and on how many variables the method relies to construct an implementation of the abstract type it returns. Abstract Factory is just that: you have another level of abstraction for creation object the Factory way (with static create method). Nothing really special about that.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Frank Silbermann:
--------------------------------------------------------------------------------

The Factory Method provides a simple decision making class which returns one of several possible subclasses of an abstract base class depending on data it is provided. (emphasis added)

The Abstract Factory Method provides an interface to create and return one of several families of related objects.

--------------------------------------------------------------------------------



Notice that the word abstract is used in the Factory Method definition -- but not in the Abstract Factory definition![/QB]



Notice also that the word abstract is used to describe the object that is returned by the factory, not the factory itself.

Of course they could have named "Factory Method" "Abstract Factory Method" instead. Well, personally I really don't care that much...
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic