[PATTERNS] What's the difference between FACTORY and ABSTRACT FACTORY methods?

[American_horizo]

I'm reading PHP object patterns and practice book, and it contain exemples for both factory and abstract factory patterns, but actually i can't understand where is the real difference.
This is the diagram of a factory exemple
[ATTACH]5095[/ATTACH]

this is the abstract facotry exemple
[ATTACH]5097[/ATTACH]

The only difference that i see is the number og generable objects, and so, the number of methods for generate it and the number of related classes (ApptEncoder, TtdEncoder, ContactEncoder).
I cant' see a real difference of design

factory.png 99.jpg

[NogDog]

Might be clearer in terms of PHP code: http://sourcemaking.com/design_patterns/abstract_factory/php/2

You'll note that the "abstract" part of the name comes essentially from the use of defining the abstract class at the top of the factory hierarchy (which is implied by the use of Italics in the class/method names in your attached diagram).

[American_horizo]

NogDog;11040147 wrote:

Might be clearer in terms of PHP code: http://sourcemaking.com/design_patterns/abstract_factory/php/2

You'll note that the "abstract" part of the name comes essentially from the use of defining the abstract class at the top of the factory hierarchy (which is implied by the use of Italics in the class/method names in your attached diagram).

The first diagram too uses abstract classes as CommsManager and ApptEncoder, fot instantiate concrete object... So why the first is factory and the second is abstract factory ?

[NogDog]

Then I would say both examples are of the Abstract Factory pattern, but one of them just shortened the name to Factory. 🙂

[American_horizo]

No, the book provide exemples for each patterns, divided by sections, so the Factory Method should refer explicitly to an exemple of factory (not abstract) pattern

[Weedpacket]

As the first paragraph on the page NogDog linked to puts it,

In the Abstract Factory Pattern, an abstract factory defines what objects the non-abstract or concrete factory will need to be able to create.

There might be more than one way to build a factory for making Foos; using an Abstract Factory means that users who want Foos made don't have to be tied down to one way to build them.

[American_horizo]

Weedpacket;11040167 wrote:

In the Abstract Factory Pattern, an abstract factory defines what objects the non-abstract or concrete factory will need to be able to create. .

Yes i understood it. But if you see the first image that should rapresent a factory (not abstarct) method, you see that it do the same... So, my doubt is about the real difference between the two methods that actually appears equals

Both factory and abstract factory UML exemples, provides an abstract class (CommsManager) that defines creable classes (such +getApptEncoder: ApptEncoder)
Both factory and abstract factory UML exemples, provides two extension of those CommsManager abstract class (Bloggs and Mega), that are concrete and are responsible of instantiate the other concrete class defined in the abstract CommsManager

The only difference i see is that in the factory method example, only ApptEncoder is defined in the abstract class, in abstract factory method is added TtdEncoder and ContactEncoder too.

[Weedpacket]

Well, a factory method is a method, while an abstract factory is an object (providing an interface consisting of factory methods). Instead of an object implementing its own factory method, it's provided with (something subclassed) from the abstract factory and delegates to the factory methods supplied by that. In your example diagrams, the factory method provides newly-constructed ApptEncoders, and depending on which implementation of CommsManager you ask, you can get a MegaApptEncoder or a BloggsApptEncoder. But that's not much help if you wanted a TtdEncoder.

Abstract factories are usually implemented using factory methods, hence the similarity of names, but factory methods aren't necessary to have abstract factories.

[American_horizo]

Weedpacket;11040173 wrote:

Well, a factory method is a method, while an abstract factory is an object (providing an interface consisting of factory methods). Instead of an object implementing its own factory method, it's provided with (something subclassed) from the abstract factory and delegates to the factory methods supplied by that. In your example diagrams, the factory method provides newly-constructed ApptEncoders, and depending on which implementation of CommsManager you ask, you can get a MegaApptEncoder or a BloggsApptEncoder. But that's not much help if you wanted a TtdEncoder.

Abstract factories are usually implemented using factory methods, hence the similarity of names, but factory methods aren't necessary to have abstract factories.

So we can say that if a class include only one method for instantiate an object is considered factory, if the same classe includes two or more method for instantiate objects it is an abstract factory?

[traq]

No. The only thing that makes a class "abstract" is that it cannot be instantiated on its own. It's like a "template," if you will. It might be fully functional, or it might have some missing methods. You have to make a concrete implementation from it in order to use it. It's like a "halfway-point" between an interface and a usable class.

Say you need factories that build foos and bars. Both objects have lots of dependencies and other set-up work, but there are a few differences, so you can't use the same factory. Solution? make an Abstract factory that has all of the common methods, then extend it to make a fooFactory and again to make a barFactory.

Or, take PHP's [man]SPLHeap[/man] class as an example. It's ready-to-go, except for the compare method, which you define yourself when you extend the class.

Or, an Abstract might have all methods defined, and you just extend it without modifications to use it. It's still helpful in case you want to change the implementation later.

---

Likewise, the only thing that makes a class a "factory" is that its purpose in life is to build other objects.

[American_horizo]

traq;11040179 wrote:

No. The only thing that makes a class "abstract" is that it cannot be instantiated on its own. It's like a "template," if you will. It might be fully functional, or it might have some missing methods. You have to make a concrete implementation from it in order to use it. It's like a "halfway-point" between an interface and a usable class.

Say you need factories that build foos and bars. Both objects have lots of dependencies and other set-up work, but there are a few differences, so you can't use the same factory. Solution? make an Abstract factory that has all of the common methods, then extend it to make a fooFactory and again to make a barFactory.

Or, take PHP's [man]SPLHeap[/man] class as an example. It's ready-to-go, except for the compare method, which you define yourself when you extend the class.

Or, an Abstract might have all methods defined, and you just extend it without modifications to use it. It's still helpful in case you want to change the implementation later.

---

Likewise, the only thing that makes a class a "factory" is that its purpose in life is to build other objects.

Uhm ok, but do you agree with me that the exemples that i've posted are equal (links below)? I don't have read other example yet, first i want to know if what i read on the book is right or not, if not, i will read other examples.
[ATTACH]5095[/ATTACH] (factory - according to the book)
[ATTACH]5097[/ATTACH] (abstract factory - according to the book)
To me it seems that they are both abstract factories

[laserlight]

American horizo wrote:

What's the difference between FACTORY and ABSTRACT FACTORY methods?

I think that the first confusion here is with the design pattern names: you are reading up on the Factory Method pattern and the Abstract Factory pattern. While saying "factory method" for the former is also correct, "abstract factory method" for the latter is potentially confusing.

Consider the intent of each of the design patterns as described by the GoF:

Factory Method: Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Abstract Factory: Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Great. This means that in both cases at least one abstract base class is involved, so using "there's an abstract base class!" as a rule of thumb to determine if the design pattern is Abstract Factory does not work. (EDIT: well, it is not actually true that an abstract base class will always be involved for the Factory Method pattern since a factory method could return an object of a concrete base class, and the base class declaring the factory method could be a concrete class with a reasonable default implementation of the factory method. However, my point stands since an abstract base class can be involved.)

American horizo wrote:

To me it seems that they are both abstract factories

Your factory.png diagram does indeed provide an example of the Factory Method pattern: the CommsManager class defines an interface for creating an object (i.e., getApptEncoder is the interface, ApptEncoder is the supertype of the object created), but it lets subclasses (MegaCommsManager and BlogCommsManager) decide which class to instantiate (i.e., by overriding getApptEncoder to instantiate a MEGAApptEncoder object and a BlogsApptEncoder object, respectively).

(EDIT: I originally wrote a "no" at the start of my previous paragraph, but I think it is not accurate: the diagram can indeed be used to represent an abstract factory. The thing is, these UML class diagrams aid in understanding, but do not describe the design patterns by themselves. Thus, insisting that a diagram used to help describe the factory method pattern actually describes the abstract factory pattern is missing the point.)

Your 99.jpg diagram does indeed provide an example of the Abstract Factory pattern: the CommsManager class provides an interface (collectively: getApptEncoder, getTtdEncoder and getContactEncoder) for creating families (ApptEncoder, TtdEncoder, ContactEncoder) of related or dependent objects without specifying their concrete classes.

It looks like the diagram for Abstract Factory is basically an expanded version of Factory Method, and indeed the GoF remark that "AbstractFactory classes are often implemented with factory methods", though they also note that "they can also be implemented using Prototype".

[Weedpacket]

laserlight wrote:

It looks like the diagram for Abstract Factory is basically an expanded version of Factory Method, and indeed the GoF remark that "AbstractFactory classes are often implemented with factory methods", though they also note that "they can also be implemented using Prototype".

So it's no surprise that the class diagram for the Abstract Factory contains the class diagram for the Factory Method within it. I wonder if it would have helped if there had been an additional diagram showing Abstract Factory implemented using Prototype as well.