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.

Remarks about the question text

I threaten with good intentions that I will someday edit the question text to remove the disparaging remarks. Such remarks are not tolerated on Programmers.SE. If you have time, please edit the question text to remove it, so that I don’t have to. Thanks.

Stated objective

I will try to greatly simplify the step-by-step transformation of the “factory-esque”. In doing so, I promise to eschew the verbiage that has long plagued the GoF patterns (and any wannabes who try to be experts on patterns).

Step zero, the constructor method

• The constructor method creates an object, initializes it, and returns the object to its caller.
• In most languages, the caller must specify the leaf-type (also known as the “most-derived type”).
• This specificity requirement is a big constraint in view of polymorphism – the caller can’t act polymorphically (i.e. “can’t pretend to not know the class”) if it needs to call a constructor, period.

Step one, ordinary factory method

• An ordinary factory method wraps the constructor method.
• It takes the arguments, constructs the object just as before (and lets the real constructor handle the actual initialization, as before), and returns it.

There are several differences.

Firstly, it removes the leaf-type specificity constraint from the caller’s code. The caller’s code now doesn’t have to know the class name of the thing it’s going to create.

Secondly, an ordinary factory method is an ordinary method. It can be:

• A static method or instance method;
• A member of the same class or of a different class;
• Or even an interface method. (This will be discussed below, in Step three.)

Thirdly, and which is orthogonal to the other differences, is that: if the object to-be-constructed-and-returned belongs to some inheritance hierarchy, the ordinary factory method doesn’t have to declare its return type (the type of object it promises to construct-and-return) to be the leaf-type. It can instead declare itself to return a base type, or some kind of interface.

This third possibility confers polymorphism to the return type of the factory method.

From this point on,

Each aforementioned orthogonal possibility can be mixed and matched to give rise to many interesting combinations; some of them are covered by the GoF book and others re-discovered by other gurus at later times.

Step two, encapsulation of multiple factory methods

Here, encapsulation simply means putting stuff into a class.

Encapsulation can have several meanings.

• Information hiding – the usual meaning, but which I’m not concerned about that now.
• Grouping of related methods into one place (a.k.a. cohesion). This will be explained here.

The factory method need not be the sole member of that class. You can have a class that has multiple factory methods. They can have different return signatures. They can return objects that belong to unrelated inheritance hierarchies.

It is you, the designer, who decrees that those two factory methods shall be united in one, and therefore you make them into a family.

Of course, a later accuser can come to you and complain that you shouldn’t have put two unrelated factory methods under the same class. But the possibility is there; use it wisely.

Step three, making compatible factory methods interchangeable by making them a member of an interface.

To do this you must have multiple factory methods that share two commonality:

• The arguments (or, the signature) to call these factory methods have identical types.
• The return type of these factory methods belong to the same inheritance hierarchy.

If the commonality exists, you can create an interface with a method that has the signature and return type. Then, you can make these factory methods callable by a client which only knows this interface.

sorry but I must stop writing now…

By having a method in Factory Method, you make it easy to customize the behaviour of a single class by simply deriving a new class from it and overriding a single method. This is simpler than needing to create an entirely new factory class to perform the same customization.

However, if multiple classes need to be customized the same way, using a separate Factory object is simpler, because then you only need to create a single new class and inject objects of that class into all of the different clients.

In reality, Factory is a much more useful pattern than Factory Method because in most situations there is more than one client and therefore the Factory can easily be shared without creating a large number of subclasses in a variety of different places in the inheritance heirarchy. It also favours composition over inheritance, which is a commonly-recommended design strategy these days. Factory Method is therefore falling out of favour and is relatively rarely used in comparison to Factory.

This Client vs Consumer is core defining feature whenever creation pattern is Factory Method or Abstract Factory. If Client and Consumer are same class, then it is Factory method, if they are different, it is an Abstract factory.

If so, why can’t the Creator method in the Factory Method be put in a separate class?

You just created Abstract Factory pattern.

Similarly, why can’t the Creator class in the Abstract Factory be the same class as the Client?

Then you reduced the whole Abstract Factory into a Factory Method.