A Sarcastic Critique of Overengineered Enterprise Java Architecture

You should ask an enterprise Java architect about this problem.

For example, just print a "hello world" in the main function? That's too procedural, too low‑level.

You need to encapsulate a class, call it Printer. Printer has a member method called print.

But a single class is too low‑level; what if you need different implementations later? So you add an interface, PrinterInterface.

However, an interface has no implementation, you still need a default implementation. So you add an abstract class, AbstractPrinter implementing PrinterInterface, and Printer extends AbstractPrinter.

Now you have this whole set, how do you create an instance? Directly new Printer() ? That's too low‑level, that's implementation dependency. It won't do, so you need a factory class, PrinterFactory, which returns an instance via PrinterInterface, hiding implementation details.

But PrinterFactory itself is an implementation class, too low‑level, so you need PrinterFactoryInterface, AbstractPrinterFactory.

And inside PrinterFactory how to write? Directly new Printer() ? Too low‑level. Still implementation dependency.

Finally, assembling all these pieces in code looks ugly, many new concrete classes. Too low!

Fortunately we have a high‑level tool called Dependency Injection! Write the whole object graph in configuration files. This whole set shouldn't reinvent the wheel. Use Spring. You also need dependency management like Maven or Gradle.

Lastly, how to pass the thing to print into the program? Hardcode? Command line arguments? Too low! It should be written in XML.

Just XML isn't enough for enterprise; add DTD validation.

Then you have to deal with XML parsing. Directly using a parser in code? Too low! You need a wrapper class with interface, abstract class, implementation class, factory class, another set. Because you can't depend on implementation; what if you change the parser later?

So the final product is a bunch of config files, a bunch of JARs, a compiled program of about 200 MB.

The IDE needs 300 plugins; opening the project makes the disk spin for ages, consumes 2 GB memory, and many plugins pop up prompts to upgrade.

Oh right, before all this you also have to draw UML diagrams.

Three years later the project is finished, deployed to the client’s server, it crashes immediately with a stack trace. The client uses JDK 5 while the new project needs JDK 6. When you ask them to upgrade, they say no because another enterprise solution only supports JDK 5, and they scold the architect for not considering a possible JDK change.