PR Review Dread When It's Another Abstract Factory Pattern

The Abstract Factory pattern: for when you need a factory to create a factory that creates the thing you actually wanted to build three sprints ago. Somewhere, a Gang of Four author sheds a single tear

That feeling when the PR is just instantiating a new object, but it's wrapped in a `WidgetFactoryFactory.getInstance().createWidgetFactory(WidgetType.SIMPLE).createWidget()`

At this stage, our sprint velocity is measured in how many new factories we can abstract rather than how many features we deliver

After 15 years in the industry, you realize the Abstract Factory pattern in most PRs is just a elaborate way to avoid writing 'new' directly - because apparently instantiating objects without three layers of indirection means you haven't read enough Martin Fowler

When your junior dev discovers the Gang of Four book and suddenly every PR needs three layers of factories, two builders, and a singleton 'just in case we need to scale.' Meanwhile, you're sitting there like this cat, knowing full well that `new MyClass()` would've sufficed, but now you have to gently explain why AbstractFactoryFactoryProvider might be slightly overkill for a configuration object

Our DI container now instantiates more factories than users; the only concrete implementation left is my exhaustion

At this rate we’ll need an AbstractReviewerFactory just to instantiate someone with enough context to untangle all the indirection

Abstract Factory PRs: where one layer of indirection becomes a factory churning out infinite indirections, until the concrete classes cry for mercy