EMZETT.
Login

Modularität in Java

Kurz: Modularität bedeutet, ein Programm in klar abgegrenzte, austauschbare Bausteine (Module) zu zerlegen. Java hat dafür seit Version 9 ein eigenes Modulsystem (JPMS, Project Jigsaw).

Genauer: Pakete ordnen Klassen, Module bündeln Pakete. Ein Modul legt in einer Datei module-info.java fest, was es braucht (requires) und was es nach außen anbietet (exports). Alles andere bleibt unsichtbar, selbst wenn es public ist.

Im Detail

// module-info.java
module de.emzett.shop {
    requires java.sql;                 // braucht das JDK-Modul java.sql
    requires transitive de.emzett.kern; // gibt diese Abhängigkeit an Nutzer weiter
    exports de.emzett.shop.api;         // nur dieses Paket ist von außen nutzbar
    opens de.emzett.shop.model to com.fasterxml.jackson.databind; // Reflection erlauben
}

Ebenen im Überblick: Klasse → Paket → Modul → JAR/Anwendung.

  • Starke Kapselung: Auch public reicht nicht, wenn das Paket nicht exportiert wird. Das schützt interne Klassen vor Missbrauch.
  • Verlässliche Konfiguration: Fehlt ein benötigtes Modul, scheitert der Start sofort mit einer klaren Meldung statt später mit ClassNotFoundException.
  • JDK modular: Das JDK selbst besteht aus Modulen (java.base, java.sql, java.net.http …). java.base braucht jeder und wird automatisch eingebunden. Mit jlink erstellt man ein verschlankte Laufzeit nur mit den benötigten Modulen.
  • Klassenpfad vs. Modulpfad: Alte Bibliotheken ohne module-info laufen weiter auf dem Klassenpfad oder als „automatische Module”.
  • Praxis: Viele Projekte nutzen weiterhin nur Maven- oder Gradle-Module (ohne JPMS). Das gliedert den Build in Teilprojekte, erzwingt aber keine Sichtbarkeit zur Laufzeit.
  • Warum modular? Übersicht, Austauschbarkeit, getrennte Tests, klare Verantwortung, weniger „Spaghetti”.
  • Allgemein: Das Prinzip gilt auch jenseits von Java: Module, Pakete, Microservices und Bibliotheken sind Formen von Modularität.

Siehe auch: Packages/API, Core, Zugriffsmodifikatoren