Revisiting the GoF patterns with a good friend and learned more about the Abstract Factory pattern.
For some reason at jobs in the past, developers always talked about the “factory pattern” and I kind of thought I knew what they meant. But looking closer at the GoF patterns, there is the Abstract Factory and the Factory Method pattern.
And the things I come across with “factory” tacked at the end, are neither.
In the wild I will usually come across a FooFactory with a static method CreateIFoo(string argument), encapsulating some basic decision logic on how to decide which subclass to return.
But the value of an Abstract Factory, being able to replace a family of related objects by other concrete classes, is never leveraged. Because OO design is hard and thus there hardly ever are any rich object models, where the opportunity and need for this would arise.
And an advantage of the Factory Method, letting you extend the supported types in a clean modular way, also isn’t leveraged. Because FooFactory is implemented as a monolithic base structure that contains all the logic to create any subclass.