Before I begin, let’s ground ourselves: a lot of things we encounter, especially in software engineering, are arbitrary. They exist because someone, somewhere, at some point, was either frustrated or passionate enough to tell other people about it. Much of software engineering terminology is bloated with non-intuitive terms describing relatively intuitive concepts—things your coworker could have spontaneously created or implemented without formally recognizing the pattern, simply because it worked and improved readability or performance.

Don’t get me wrong—there are indeed brilliant ideas developed by exceptionally smart people. Nevertheless, let’s always keep in mind this illuminating perspective by Malcolm Gladwell from his book Outliers:

“Superstar lawyers and math whizzes and software entrepreneurs appear at first blush to lie outside ordinary experience. But they don't. They are products of history and community, of opportunity and legacy. Their success is not exceptional or mysterious. It is grounded in a web of advantages and inheritances, some deserved, some not, some earned, some just plain lucky—but all critical to making them who they are. The outlier, in the end, is not an outlier at all.”

What are Creational Patterns?

Design patterns generally exist to make our cost more readable, maintainable, and efficient, right? Creational patterns specifically deal with the management of object creation. At this point, if you’re wondering why the hell you should care, that’s perfect. I’m wondering that too.

So What?

From my perspective, it would be quite beneath us as software engineers to not prioritize easing each other’s burdens. Yet, I say this rather confidently while treading with caution, not because I am afraid of the harsh backlash that comes with opinions but rather to give the community its rightful recognition—another’s perspective, confusion, and frustration due to our lack of congruence seems to be towards the bottom of our checklists. Patterns exist precisely because they are repeatable solutions to common problems. Let’s use them and free ourselves to build whatever we wish such that collaboration does not hold onto a negative connotation.

Factory Method (a.k.a “The Lab”)

To be clear, I’m not a huge fan of the term “Factory”. It conjures images of industrial assembly lines, machinery, and uniformity—not necessarily the creativity or flexibility we often associate with innovation, creativity, and the art of software engineering. Yet, I understand why it was chosen:

• Factories mass-produce goods. Similarly, the Factory Method mass-produces objects.

• Factories abstract away the details of creation. Likewise, the Factory Method abstracts object instantiation logic, keeping those that use these objects in a clean room.

But why not call it something more evocative or descriptive? What if we called it a “Lab” instead? That signifies a place where objects are methodically but innovatively created, tested, and refined, reflecting software engineering’s blend of creativity, discipline, and, if we’re really gunning for it (although I have counseled not to say this, I SHALL NOT BE SILENCED), mysteriousnesssssss.

Okay, so what is the Factory Method, really?

At its core, the Factory method:

• Defines an interface or blueprint for creating an object that allows subclasses to alter the type of objects that will be created.

• Encapsulates object creation, promoting LOOSE coupling between client classes and concrete classes (because what if you change your mind? that never happens, right?).

• Reduces redundancy… Okay, but let’s talk about this real quick.

  

Consider a scenario:

• You’re building a ticketing application that supports multiple ticket formats like Apple Pass, Google Pass, or other mobile wallet passes, collectively known as One Pass tickets.

• You create a base class, TicketCreator, with a method like createTicket().

• Subclasses like ApplePassCreator and GooglePassCreator override this method, returning instances of their respective ticket classes.

• Your client code can seamlessly request ticket creation without knowing what’s behind the curtain. It simply calls createTicket(), abstracted entirely from the much more complex logic underneath.

I would like to note that this is a dramatic simplification of ticketing platforms and how these are created, but they can definitely benefit from modularization and the factory method pattern.

But seriously, why a “Factory”?

It was coined by the GoF. Don’t ask me. Metaphorically, it aligns quite nicely with the industrialization, pre-actually-caring-about-how-things-look, mindset—repeatable, predictable, efficient. Yet today, software development is less about monotonous repetition and more about adaptability and innovation. So perhaps we should evolve our metaphors to match our realities. A “Lab” captures the iterative, innovative, and creative aspects of our work rather nicely.

Final thoughts

The Factory Method remains undeniably valuable. However, questioning terminology and conventions pushes us forward, refining how we communicate and collaborate. I’ll be honest—I did not grow up with the vocabulary used to describe these things. Talking about the factory method, creational design patterns, and other technical concepts allows us to first firmly grasp it. Software engineering thrives not on dogmatic adhere to tradition (I would hope) but on continuous re-evaluation and improvement.

So next time you implement the factory method design pattern, maybe take a moment to think. Wouldn’t a lab coat suit a llama better than a hard hat?