What is a Factory in OOP

Question

My understanding of "factory-related" design patterns and their OOP-implementations has always been pretty simple.

• A "Factory method" is a method inside a class that has an interface (or an abstract class) as a return type and constructs objects implementing this interface based on some internal logic.
• A "Factory" is a class that only contains factory methods
• An "Abstract factory" is an interface (or an abstract class) that only contains factory methods

But I recently stumbled upon Wikipeda articles on the subject (Factory, Abstract factory) that made me somewhat confused, especially about what a "Factory" is in OOP.

Here are several quotes:

1. A subroutine that returns a "new" object may be referred to as a "factory", as in factory method or factory function.
2. Factories are used in various design patterns
3. The "Abstract factory pattern" is a method to build collections of factories.
4. A factory is the location of a concrete class in the code at which objects are constructed

which arouse some questions:

(1)&(2) Does this mean that a factory is not a class or an object, but a piece of logic?

(2) Is "Factory" not a pattern itself?

(3) What does "collection" mean here? Is it just a way of saying "you can have several factories that implement the same interface (which is an abstract factory)"?

(4) What???

Can anyone clarify what this means? Is my initial understanding of factories incorrect?

Answer 1

Look at this wiki which says:

In object-oriented programming (OOP), a factory is an object for creating other objects – formally a factory is a function or method that returns objects of a varying prototype or class from some method call, which is assumed to be "new".[a] More broadly, a subroutine that returns a "new" object may be referred to as a "factory", as in factory method or factory function. This is a basic concept in OOP, and forms the basis for a number of related software design patterns.

So to answer your questions specifically:

(1)&(2) Does this mean that a factory is not a class or an object, but a piece of logic?

No, it means that you can create other objects using an object(factory).

(2) Is "Factory" not a pattern itself?

There are different design patterns out of which factory pattern is one. So when you are creating objects using a factory then that patter of creating other objects is "Factory pattern"

Answer 2

I think you generally have it right. But, people don't like general, so it's the specifics where things go pear-shaped.

There a few things to consider:

• Wikipedia is sometimes woefully bad on technical subjects because they are trying to get to a single answer where different domains or programming languages may use the terms slightly differently. Not only that, many people are not skilled at technical writing and forget that Wikipedia is for the masses, not a graduate-level computer science theory class. As such, they tend to overly focus on minutiae or use language more complicated than necessary. So, don't worry about Wikipedia. And, although there is an edit history, no real names tend to be attached to these and no one really cares who wrote which words, so no one is that motivated to do that well. Having expressed that quite cynical opinion of the whole endeavor, reading the Talk pages are very interesting, in a Cunningham's Law sort of way.

• (2) The name "Factory" is a pattern, but remember that patterns are general ideas, not implementations. Different languages may employ the same idea in different ways, and those different ways may not agree. A particular language or community starts to use the term in the way most meaningful to them, however, despite what anyone else thinks. That idea may show up in bare, procedural logic; classes; objects; or whatever the tool provides.

• Design Patterns (the book(s)) are generally describing shortcomings in tools. They also aren't really design patterns in the way the authors think they are. Mark Jason Dominus has a wonderful talk on this, "Design Patterns" Aren't. His basic idea is that the Gang of Four misunderstand Christopher Alexander in that they (accidentally) prescribe solutions rather than promote the idea of a locally-relevant architectural language. So, the Gang of Four patterns become reified in languages almost exactly as the described single possible solution. Readers then force those patterns as a globally-relevant language completely disconnected from what you personally are trying to build, then argue about what it all really means out of any sort of context using extremely ill-suited examples that don't matter to what anyone is trying to build. There's no reason your recommendation engine and someone's first person shooter should have the same architectural language other than your tool forcing it on both of you. FWIW, paying attention to Mark Jason Dominus is a very good professional development move. His Higher-Order Perl is one of the best programming language books I've read and certainly better than anything I've written. He knows a lot of different languages (and languages that are very different) and thinks very deeply about things.

• In (3), the term "collection" is unfortunate because we tend to use that to mean a set of things that co-exist at a particular time in the same container (box, book, whatever). I think they are trying to suggest that the abstract factory is a template for future factories that cannot be presently enumerated, which is a fancy way of saying that we can use it to build factories we don't even know about yet.

• In (4), the term "location" is unfortunate. An abstract factory is a way of producing concrete factories, which is a way of producing objects.