Skip to Content.
Sympa Menu

patterns-discussion - RE: [patterns-discussion] Abstract Factory vs. Factory Method

patterns-discussion AT lists.cs.illinois.edu

Subject: General talk about software patterns

List archive

RE: [patterns-discussion] Abstract Factory vs. Factory Method


Chronological Thread 
  • From: Russell Dodd <rdodd AT hhh.co.uk>
  • To: patterns-discussion AT cs.uiuc.edu
  • Subject: RE: [patterns-discussion] Abstract Factory vs. Factory Method
  • Date: Thu, 30 Oct 2003 14:42:43 -0000
  • List-archive: <http://mail.cs.uiuc.edu/pipermail/patterns-discussion/>
  • List-id: General talk about software patterns <patterns-discussion.cs.uiuc.edu>

The FactoryMethod pattern is easy to use in any situation where inheritance
is involved. The parent class can define an abstract method that requires
child classes to provide specific implementations of an object. E.g. (in
Java):

public abstract class Warehouse {
public void restackCrates() {
// prepare some stuff
getCreateStacker().stackCrates();
// tidy up some stuff
}
public abstract CrateStacker getCrateStacker();
}

public class PyramidWarehouse extends Warehouse {
public CrateStacker getCrateStacker() {
return new PyramidCrateStacker(); // class not shown
}
}

public class TowerWarehouse extends Warehouse {
public CrateStacker getCrateStacker() {
return new TowerCrateStacker(); // class not shown
}
}

This allows us to implement most of our restackCrates functionality in the
parent class, but leave the actual stackCrates job to the specific
implementations provided by the factory methods of the subclasses.


The AbstractFactory pattern differs in that it is classes specifically
designed for constructing groups of related classes. For instance (again, in
Java) your application could have abstract 'ApplicationInterfaceFactory'
class or interface:

public interface ApplicationInterfaceFactory {
public MainMenu createMainMenu();
public DataEntry createDateEntry();
public ResultsPresentation createResultsPresentation();
}

and we then supply as many implementations of this interface that provide
related classes:

public class AWTInterfaceFacory {
public MainMenu createMainMenu() {
return new AWTMainMenu();
}
public DataEntry createDataEntry() {
return new AWTDataEntry();
}
public ResultsPresentation createResultsPresentation();
return new AWTResultsPresentation();
}
}

public class SwingInterfaceFacory {
public MainMenu createMainMenu() {
return new SwingMainMenu();
}
public DataEntry createDataEntry() {
return new SwingDataEntry();
}
public ResultsPresentation createResultsPresentation();
return new SwingResultsPresentation();
}
}

public class CLIInterfaceFacory {
public MainMenu createMainMenu() {
return new CLIMainMenu();
}
public DataEntry createDataEntry() {
return new CLIDataEntry();
}
public ResultsPresentation createResultsPresentation();
return new CLIResultsPresentation();
}
}

public class AudioInterfaceFacory {
public MainMenu createMainMenu() {
return new AudioMainMenu();
}
public DataEntry createDataEntry() {
return new AudioDataEntry();
}
public ResultsPresentation createResultsPresentation();
return new AudioResultsPresentation();
}
}

As you can see, each of the subclasses provides a set of related objects to
the client object. An AbstractFactory pattern is a bit like a collection of
FactoryMethod patterns.

Hope that wasn't too code intensive ;-)

Russell Dodd

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

From: Pablo Schor
[mailto:pablo.schor AT lobruno.com.ar]
Sent: 30 October 2003 13:11
To:
livingmetaphor AT yahoogroups.com;

patterns-discussion AT cs.uiuc.edu
Subject: [patterns-discussion] Abstract Factory vs. Factory Method


I've been using the factory pattern for a while, but don't know exactly if
I'm using the Abstract Factory or the Factory Method. They look the same to
me, but what are the differences?



thank you,


Pablo


**************************************************************************************
This E-mail transmission may contain confidential or legally privileged
information that is intended for the addressee only.
Any views or opinions presented are solely those of the author and do not
necessarily represent those of Hill House Hammond. If you are not the
intended recipient you are hereby notified that any disclosure, copying,
distribution or reliance upon the contents of this E-mail is strictly
prohibited.
If you have received this e mail in error please notify the sender
immediately,
or our IT department by return e mail to
ITSEC AT hhh.co.uk.
Hill House Hammond will then arrange for its proper delivery.
Please then destroy this e-mail, any copies of it and delete it from your
inbox.
Hill House Hammond monitor mail for unauthorised use and viruses,
however addressees should check this e mail for viruses as Hill House
Hammond do not guarantee the absence of viruses
**************************************************************************************

Head Office: Hill House, Lewins Mead, Bristol BS1 2LL
Registered Office: 8 Surrey Street, Norwich, NR1 3NG
Registered in England Number 2624984.

Hill House Hammond Limited is an independent intermediary, a member of the
General Insurance Standards Council and a subsidiary of Norwich Union
Insurance Limited,
an associated company of Aviva plc, and Haven Insurance Policies Limited.
Introducer only to Norwich Union Marketing Group members of which are
Authorised and regulated by the Financial Services Authority.





Archive powered by MHonArc 2.6.16.

Top of Page