Jetzt noch ein weiterer Aspekt von Modularität, ein sehr moderner Aspekt.
Und das ist dir ja, vor dem ich schon eingangs gewandt hatte,
Vorsicht. Hier wird jetzt ein Name, ein Bezeichner,
eine Bezeichnung zweimal verwendet, nämlich der Begriff Modul.
Wir haben Modularität als Konzept für zusammenfassend verallgemeinern Zugriffsschutz strukturieren, von großen Systemen.
Und jetzt gibt es diesen Begriff Modul nochmal als Sprachelement in Java.
Das Sprachelement in Java wurde deswegen eingeführt, weil Pakete
ein paar Nachteile hatten. Ich hatte das eben schon gesagt,
als wir über Pakete gesprochen haben, Public-Elemente,
Public-Klassen von Java sind in allen Paketen überall sichtbar.
In großen Projekten ist uns das manchmal zu viel. Wir wollen das verhindern,
weil wir bestimmte Klassen haben, die müssen zwar sichtbar sein,
aber sie sollen nicht für alle sichtbar sein,
sondern vielleicht nur innerhalb eines solchen Paketes oder innerhalb von Nachbarpaketen.
Diese Sichtbarkeitseinschränkung soll dazu dienen, nicht etwa,
weil wir Programmierer ärgern wollen, sondern sie sollen dazu hindern,
dass wir Änderungen nicht so weit sich ausbreiten lassen.
Wenn wir etwas haben, was nur hierrin sichtbar ist,
dann sind auch Änderungen, davon resultieren,
weil wir in der Klasse etwas geändert haben, auch darauf beschränkt.
Woanders wirkte sich nicht aus. Und das wollen wir erreichen.
Das braucht man in großen Projekten. Das ist der eine Punkt
. Und der nächste Punkt, damit wir die Auswahl,
welches Paket wirklich dazugehört, passiert in Java über die variable Glass-Path.
Das heißt, wir konfigurieren das Paketkonfiguration, heißt Anordnung.
Welches Paket gehört zu einem System? Das steuern wir über
die Reihenvölker vom Glass-Path. Und das ist leider relativ fehleranfällig,
insbesondere wenn wir viele Pakete haben. Und deswegen wurde in
Java 9 mit dem Projekt Jigsaw wurden Module als Sprachelement eingeführt.
Bitte, wie gesagt, Vorsicht. Wir sprechen jetzt von
dem Sprachelementmodul, nicht von dem Modul als Zusammenfassungskonzept.
Und zwar mit dem Ziel, Sichtbarkeit, explizit zu steuern.
Ja, und das ist auch gleichzeitig die Antwort auf diese Frage.
Wir springen mal kurz vorne hin zu der Frage,
Moment, ich muss hier auch erst umschalten, Folie 4.
Und zwar hier Frage 5, welche Steuerungsmöglichkeiten über Pakete hinaus schaffen die Ja,
war Module, dass wir es explizit steuern können.
Ja, also diese Sichtbarkeit explizit steuern, das ist das Ziel.
Weitere Vorteile bestehen darin, dass wir den Corm Piler einsetzen können,
um zu prüfen, ob tatsächlich die Konfiguration gültig ist,
ob die Sichtbarkeit stimmt und natürlich auch, was heißt natürlich,
das ist ein großer Vorteil, dass Zyklen vermieden wir.
Gleichzeitig gibt es dafür die Konfiguration aussagekräftige Fehlermeldungen und wir haben
richtig die Möglichkeit, richtig mit APIs zu arbeiten.
Das gehört zur API und andere Sachen nicht,
indem wir sie ausschließen von der Weiterabgabe
So, was sind da die Regeln?
Ich habe das hier mal als Sprechblase mit reingepackt.
Wir sprechen jetzt von den Java-Modulen, die es ab neun gibt.
Vielleicht sollte ich noch dazu sagen, es gibt bis jetzt
sehr wenige Projekte, die das benutzen.
Das ist ein sehr modernes Sprachkonzept. Ich möchte es auch
hier wenigstens kurz erwähnen. Wir gehen da nicht sehr in
die Tiefe. Wir gehen gleich auch zum nächsten Thema.
Also jedes Paket darf nur von einem Modul implementiert werden.
Das ist eine Regel, die gegeben wird.
Zyklen sind verboten. Das Wissen Informatiker sowieso,
Zyklen sind böse
War nicht deswegen, weil wir sagen,
dass unsere Ästhetik wird da verletzt, sondern deswegen, weil die Testbarkeit,
wenn wir etwas seine testen und dann das andere noch dazu,
was ist Umgebung, was ist nicht Umgebung,
das wird echt schwierig, wenn wir Zyklen haben,
die Verständlichkeit natürlich, aber vor allen Dingen die Änderbarkeit.
Wenn wir das eine updaten und das andere hängt davon ab,
müssen wir sie unbedingt immer gleichzeitig einspielen und wir wollen versuchen,
inkrementell zu arbeiten,
Scrum und die ganzen Methoden sind letztlich auf inkrementelles Arbeiten vorgesehen
Eine weitere eigentliche Information, die ich Ihnen dazu geben möchte,
es gibt eine Diskriptordatei. Es gibt eine Dateimodul-Info. Java,
das ist nicht etwa eine Quellcode oder eine Bitecode-Datei,
sondern das ist diese Skriptodatei, die wirklich die Sichtbarkeitssteuer dasteht,
das drin, was wir sehen wollen.
So, wieder, wir sind immer bei dem Java-Modulen,
wenn wir also so in der Mediathek ja eine Public Klaas
haben und dann steht dort drin in der Infodatei,
dass wir die exportieren, dann ist die für alle sichtbar.
Ja, weil wir eben mediathek.fachwerte hier exportieren. So,
wenn wir nur sichtbar machen,
etwas nur sichtbar machen für Klassen im selben Modul,
ja, dann würde hier Public Class Kundennummer, ja,
wird sichtbar,
wenn wir nur Mediathek exportieren ohne weiteres.
Ja, so
Das Konto, die klasse Konto, die hier sichtbar sein soll,
für alle Klassen im selben Modul und für zusätzlich ein Modul SE3,
dann dasselbe Modul ist sowieso klar,
weil hier oben Public steht.
Und wenn wir sagen wollen, wir wollen sie zu SE3 exportieren,
können wir das auch noch angeben.
Das sind eine weitere Möglichkeit. Also soweit kurz,
das sind die Möglichkeiten, die wir hier mit diesem Konzept haben.
Ja, im Überblick, also das ist mit Java 9 eingeführt worden.
Wie gesagt, es haben noch nicht viele Java-Projekte,
die davon wirklich einen nutzen von ziehen.
Und weiter geht es dann mit dem nächsten Konzept,
die mit