YAGNI in Java

YAGNI in Java

In Java, this often happens when developers add extra classes, methods, or features “just in case.”

🚨 Without YAGNI (Over-engineering)

public class ReportGenerator {

    // Feature not needed right now, but added "just in case"
    public String generatePDFReport(String data) {
        // Pretend to generate PDF (not needed yet)
        return "PDF Report: " + data;
    }

    public String generateExcelReport(String data) {
        // Pretend to generate Excel (not needed yet)
        return "Excel Report: " + data;
    }

    public String generateReport(String data) {
        // Current requirement: only plain text
        return "Text Report: " + data;
    }

    public static void main(String[] args) {
        ReportGenerator rg = new ReportGenerator();
        System.out.println(rg.generateReport("Sales Data"));
    }
}

🔴 Problem:

  • The project only needed text reports, but developer added PDF and Excel support prematurely.
  • This increases code size and future maintenance work.

✅ With YAGNI (Simplified, Only What’s Needed)

public class ReportGenerator {

    // Only build what’s required now
    public String generateReport(String data) {
        return "Text Report: " + data;
    }

    public static void main(String[] args) {
        ReportGenerator rg = new ReportGenerator();
        System.out.println(rg.generateReport("Sales Data"));
    }
}

✅ Benefits:

  • Less code → fewer bugs.
  • Easier maintenance.
  • If PDF/Excel is ever required, it can be added later (when there’s a real need).

🔑 YAGNI in Practice

  • Don’t design for future requirements you think might happen.
  • Implement only the features needed now.
  • Future-proof with clean architecture, not speculative code.

Leave a Reply