Your distinction is not generally correct. For example, the Abstract Factory Pattern uses the Factory Method Pattern. In the Factory Method Pattern, the classes using and providing the factory method need not be the same class.
An Abstract Factory class has object creation as its sole concern. If an abstract factory instance were its own client, this would be a violation of the Single-Responsibility principle.
Below, you'll find a discussion of factory methods, the Factory Method Pattern, the Abstract Factory Pattern, and comparisons between them and other patterns.
Factories or Simple Factories or Factory Methods
A factory is any function that is used to create some data structure. In OOP languages, constructors are often special factory methods that can't be used freely (e.g. you often can't explicitly return something). By wrapping construction in an ordinary method, we can add validation, preprocessing, or further initialization code, and can return objects of different types depending on context. By using factory methods, users are insulated from the specifics of object construction – if we want to switch the type of some object, we only have to change the code inside the factory, and not all the code using that factory.
Simple factories are not a Go4 pattern, but form the basis of many patterns such as the Factory Method Pattern, Abstract Factory Pattern, and the Builder Pattern.
Factory Method Pattern
In the Factory Method Pattern, we have a class that contains an overridable factory method. Subclasses are encouraged to override this method to change the type of the returned object. Pseudocode:
interface Product { … }
class DefaultProduct implements Product { … }
class SpiffyProduct implements Product { … }
class Creator {
virtual Product create() { return new DefaultProduct() }
}
class OtherCreator extends Creator {
override Product create() { return new SpiffyProduct() }
}
// client code:
Creator c = ...;
Product = c.create();
Note that Creator::create is a factory method/simple factory. However, the identifying property of the Factory Method Pattern is the usage of inheritance to change the factory method.
The advantage of the Factory Method Pattern is that in order to change the factory method used in client code, we only have to change the line where the Creator c is obtained/created. This flexibility allows the Factory Method Pattern to be used for simple Dependency Injection tasks.
Variations
If we use the Factory Method Pattern and the client is in the same class as the factory method, then this can also be described as the Strategy Pattern applied as a creational pattern.
The root Creator class need not be instantiable, or provide some default product. Instead, it could be abstract or an interface.
One object can reasonably implement the Factory Method Pattern multiple times for different Products. If object creation is the main purpose of the creator and the different products are related, this is probably better described as the Abstract Factory Pattern.
The Factory Method Pattern is usually used as a helper in order to achieve that object's main concern (e.g. when used in combination with the Strategy Pattern). If the factory method is the only method of a class implementing the Factory Method Pattern, this can also be viewed as an example of the Command Pattern.
Abstract Factory Pattern
The Abstract Factory Pattern uses the Factory Method Pattern to create a palette of related objects. Or: the abstract factory instance is that palette.
While the Factory Method Pattern is often used as a helper to do something else, the main concern of a factory object in the Abstract Factory Pattern is always object creation. As such, the client is always supposed to be a different class, although an abstract factory could also use itself, e.g. to assemble a composite object.
