When the 30-year-old OOP purist takes dependency injection too far
Description
White-background meme titled "The 30 year old OOPer" sits above a blurred Wojak-style character in the center. Surrounding text mocks extreme object-oriented habits: "Project has 412 folders, 13,571 classes and not a single If statement because If statements are unclean, literally unreadable spaghetti", "D.R.Y. fundamentalist (except for the 500 near identical overload methods)", "Begins each new project with PrimordialSpaceTimeFabric (implements IExitable) as a base class for everything else". On the right, verbose class naming is parodied with "BaseContextGeneratorMiddlewareConfiguratorStrategyFactory" and its instantiation line "baseContextGeneratorMiddlewareConfiguratorStrategyFactory = new BaseContextGeneratorMiddlewareConfiguratorStrategyFactory();". Further right: "His 6 cats are named Public, Static, Void, Main, String and Args". At bottom right a bold caption screams "I'm gonna- I'm gonna inject a DEPENDENCYYYYYYYYYYYYY". The meme satirizes over-abstraction, massive class hierarchies, dogmatic DRY enforcement, verbose Java/.NET naming, and compulsive dependency injection - highlighting how such practices lead to unreadable code, code smells, and mounting technical debt
Comments
6Comment deleted
Seeing PrimordialSpaceTimeFabricFactoryStrategy injected into its own middleware to “eliminate if-else” is peak OOP: you haven’t removed the branch, you’ve just offloaded it to the call stack - and doubled the AWS bill for the ceremony
The guy who spent three sprints abstracting a simple config file into a 47-class hierarchy is now explaining why your straightforward solution "doesn't scale" - meanwhile his microservice takes 3GB of RAM to return "Hello World"
After 15 years of enterprise Java, you don't just inject dependencies anymore - you inject BaseContextGeneratorMiddlewareConfiguratorStrategyFactory instances through AbstractSingletonProxyFactoryBean wrappers. Your codebase has more layers than a wedding cake, more interfaces than a networking conference, and enough XML configuration to deforest a small nation. You've convinced yourself that 412 folders and 13,571 classes represent 'clean architecture,' while secretly knowing that the real reason you avoid if statements is because finding where business logic actually executes requires a distributed tracing tool and a prayer. Your cats are named after Java keywords because even your personal life has been dependency-injected into the Spring container of existence
When you ban if-statements and end up with 13,571 classes, congrats - you’ve implemented a distributed switch statement and hired the DI container to manage the org chart
He replaced the last if-statement with BaseContextGeneratorMiddlewareConfiguratorStrategyFactoryFactory and 14 constructor params - SOLID on paper, fossilized in production
His DI container resolves more abstractions than actual business logic - classic case of SOLID turning into 'So Overly Layered It's Dysfunctional'