File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Abstract Factory Responsibility Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Abstract Factory Responsibility" Watch "Abstract Factory Responsibility" New topic

Abstract Factory Responsibility

Graham Mead
Ranch Hand

Joined: Sep 28, 2001
Posts: 57
I wonder if someone could clarify something for me with regards to the Abstract Factory Pattern
My question is which entity should be responsible for deciding which concrete factory object should be instantiated.
I've been reading Alan Shalloways very good book Design Patterns Explained that implies that it should be the Abstract Factories job to do this.
Does it matter that the AbstractFactory may then acquire some implementation awarenesss to achieve this?
However I have also seen many other examples where the client or app control program instantiates the concrete factory directly. This seems to slightly negate the abstraction of the Abstract Factory class and its point in existing apart from tying the concrete factories together.
Any views would be appreciated.
Graham Mead
Tauqueer Ali
Ranch Hand

Joined: Sep 05, 2001
Posts: 53
Hi Graham,

-My question is which entity should be responsible for deciding which concrete factory object
should be instantiated.
An abstract factory is a class whose purpose is to instantiate a family of classes -- an object
maker. In its simplest form, there is one "factory" class used to instantiates subclasses.The
entity responsible for deciding which concrete factory object to instantiate
is usually
a system property. The Abstract factory class reads this property and decides at runtime which
class to instantiate. This allows the factory to change its implementation without necessitating a
- Does it matter that the AbstractFactory may then acquire some implementation awareness to achieve
If the concrete class to be instantiated is decided at runtime, the factory is spared from
the awareness of different implementations. This is very important and is in fact the main
principle behind this pattern. Its important to note here that the Abstract Factory Pattern along
with a few other patterns is a part of bigger design approach called Protected variations(Larmnan).

In Larman's words PV is:
Identifying points of predicted variation and creating a stable interface around them.
This approach lets you change or parameterize a system´┐Żs behavior through external logic
expressions. The system is protected from the impact of logic variations by externalizing the logic,
reading it in (for example, rules), and using an interpreter.
If you understand this, you can easily realize the importance of Factory not being aware of
the concrete implementations.

Lets consider an example.
The Java API for XML Processing (JAXP) enables applications to parse and transform XML documents
independent of a particular XML processing implementation. This ability is a direct result of
employing an abstract factory design pattern.

The JAXP specification does not provide any implementation. Vendors provide the actual
implementation (i.e. concrete classes that implement the interfaces or extend the abstract classes)
of the specification;
The factory implementation that is used is controlled by the
runtime property
(the deciding entity). This allows the parser to change without necessitating
a recompile.

A client code using SAXParserFactory may look like this.
SAXParserFactory factory = SAXParserFactory.newInstance();
SAXParser parser = factory.newSAXParser();
This program is unaware of any specific implementation of SAXParser. It simply gets a new instance
of factory and requests the factory to provide a SAXParser.

Here's the source for SAXparserFactory class
source for SAXParserFactory .java
public static SAXParserFactory newInstance()
throws FactoryConfigurationError
try {
return (SAXParserFactory) FactoryFinder.find(
/* The default property name according to the JAXP spec */
/* The fallback implementation class name */
} catch (FactoryFinder.ConfigurationError e) {
throw new FactoryConfigurationError(e.getException(),

source for
static Object find(String factoryId, String fallbackClassName)
throws ConfigurationError
ClassLoader classLoader = findClassLoader();
// Use the system property first
try {
String systemProp =
System.getProperty( factoryId );

if( systemProp!=null) {
debugPrintln("found system property" + systemProp);
return newInstance(systemProp, classLoader);
} catch (SecurityException se) {

Here the factory looks at the system property to decide which concrete factory implementation
is required and instantiates it.
Hope that helps,

SCJP2, SCWCD, XML, OOAD<br />Kolkata, India
Graham Mead
Ranch Hand

Joined: Sep 28, 2001
Posts: 57
Cheers Ali, it does help
That was the way I was leaning but its nice to have someone else on your side.
Thanks for your time and effort
Ilja Preuss

Joined: Jul 11, 2001
Posts: 14112
The intent of the Abstract Factory pattern is to decouple "when to create an object" from "what actual (sub)type of object to create".
So, the critical part is that *the client* of the Abstract Factory doesn't know or care about the actual factory, but just works with the one given to it from the outside.
Afaik, how to decide about the actual instance of the factory isn't part of the pattern - it could be anything from configuration by a file to the hardcoded instantiation in a specific part of your application.

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
I agree. Here's the link:
subject: Abstract Factory Responsibility
It's not a secret anymore!