Das nächste Prinzept, das wir behandeln als Modularität, sind Pakete.
Pakete sind in Java durch Packages abgebildet und Packages sind ein Modulkonzept,
was etwas größer ist, als das einer Klasse.
Deswegen haben wir durch so Sachen oberhalb.
Und sie haben wieder die typischen Eigenschaften, Strukturierung,
sie dienen dazu, Zusammengehöriges zusammenzupassen. Das heißt,
wir tacken packen Sachen in ein Paket, die dazugehören,
die kleineren, eigentlich kleineren Einheiten können darin enthalten sein.
Das wären also Klasseninterfaces,
aber auch selbst Pakete
Und die haben auch wieder die Eigenschaft zur Entkopplung beizutragen,
indem sie Kapselung ermöglichen. Sie beschränken nämlich den Zugriff.
Sie bilden außerdem einen Namensraum und was für Java für den
ganz praktischen Gebrauch sinnvoll ist. Sie sind eine Übersetzungseinheit,
das heißt ein Paket kann mit einmal übersetzt werden.
Sie dienen als solches zur Strukturierung, wir brauchen weniger Einheiten,
wir haben kleinere Einheiten und sind damit besser geeignet,
um Komplexität zu beherrschen.
Hier stehen, haben wir das Symbol der OML, das Paketsymbol,
das ist ein Rechteck mit so einem Reiter obendran oder nur ein Rechteck,
wo drinsteht, mit Spitzenklammern.
Pekic, das wäre das Gleiche.
Ihr hat meine So, hat man
das so gemacht
Dass man im Reiter den Namen reingeschrieben hat, das muss man
aber nicht manchmal später Paketname auch hier drin. Ja,
also hier sieht man, hat man immer im Paket,
haben wir ein weiteres Paket angegeordnet, in Paketen,
Klassen und also im Paket A, B,
C ist das Paket UVW drin enthalten und das Paket UVW-Paket A,
B, C enthält zusätzlich noch zwei Klassen und hier ein Interface.
Eine davon hat eine so eine Klasse, ist eine öffentliche Klasse,
die kann also von außen benutzt werden,
hier in unserem Beispiel dargestellt, durch eine Benutzungsbeziehung,
Benutzungsbeziehung wiederum gestrichen,
die Linie ist eine Abhängigkeit,
gestrichene Linie mit diesem in Spitzenklammern News dazu
ist eine Benutzungsbeziehung
So viel immer mal zur UML-Syntax. Ich schicke mir mal
das Bildchen hier ein Stückchen hoch, dass sie gut den,
dass die Foliennummer sehen können und das selber mitverfolgen können.
Was hat das mit dem Namensraum auf sich? Der Namensraum
ist dafür gut oder hilft uns dabei, Kondinamenskonflikte zu vermeiden,
gerade in großen Systemen gibt es durchaus den Bedarf,
dass Namen mehrfach verwendet werden können oder es gibt besonders häufige Namen.
Ja, tatsächlich kann man,
obwohl der Name List oder Pfeil woanders schon definiert ist,
kann man ihn innerhalb eines Paketes nochmal neu für was
anderes verwenden
Dieser Name, der Paket des Paketes,
es wird Bestandteil des Namens für Klassen- und Interfaces,
die in dem Paket enthalten sind. Ja, also wenn,
das ist sozusagen ein Prefix hervorgesetzt, eingefokussiert,
war Namensbestandteil und der volle Name hat dann immer den Namen des Pakets davon.
Also die Klasse Punkt mit einer Operation Ursprung,
wenn die im Paket Grafik steht, dann wäre der volle Name crafics.punkt.ursprung.
Und dieser, wenn wir das,
wenn wir das innerhalb des Paketes sind,
brauchen wir das crafics davor nicht anzugeben,
aber außerhalb ist das
die eindeutige Bezeichnung davon
Gleichzeitig gibt dieser lange Name der vollqualifizierte Name die Möglichkeit,
die Eindeutigkeit leichter zu erzeugen, was finden wir hier oben sagen,
man kann also Namen mehrfach vergeben, ja,
wir aber für ein Paket sind nur einmal da und deswegen
eine Klasse kann nur zu einem Paket behören.
Gleichzeitig bittet die Klasse,
wie wir eben auf der vergangenen Folie schon hatten,
durch die Kapselung oder eine Kapselung durch Zugriffsbeschränkung und nur das,
was mit Public gekennzeichnet ist, ist außerhalb des Paketes sichtbar.
Das trifft so,
wie sonst für Operationen Zugriff zugreifbar ist außerhalb von Klassen,
so ist das für Klassen,
außerhalb von Paketen
Kein Multi-Fire ist, also keiner so ein Bezeichner auch für Public Private oder was ähnliches,
dann ist es nur innerhalb des gleichen Paketes sichtbar.
Wir geben im Quelltext an,
dass es sich um ein Paket handelt, das heißt,
wir likarieren denn das Paket am Anfang einer jedem Datei an jedem Übersetzungseinheit,
zum Beispiel hier Package und dann kommt Graphics für diese Graphics,
für das Kaffeespaket, deswegen ein Open-Beispiel haben.
Und man kann natürlich eine Datei machen,
die keine so eine Bezeichnung hat,
dann gibt es das sogenannte Default-Package,
das ist dann der gesamte Rest,
wo ich für kleine Projekte brauche,
dann einfach
kein Paket anzugeben
Wie vergeben wir Namen und wie nützen wir das für die Schachtelung?
Der Paketname sind diese mehreren Teile,
die Punktnotation im Fall qualifizierten Namen hatten wir eben schon gesehen.
Und es sind sogar möglich, das ist sogar möglich,
dass ich den Namen mehrfach von eines Pakets mehrfach verwende,
eben wenn es da rüber liegend ein Paket gibt,
was für die Unterscheidung Zugriff zutrifft.
Das war weltweit, das weltweite Koordinieren ist nicht so richtig möglich.
Deswegen gibt es eine Konvention, also eine Vereinbarung,
wie man damit umgeht. Und diese Vereinbarung ist so,
dass man die Internetdomänen-Namen als Präyefix nimmt, da vornimmt.
Ja, aber mit umgekehrter Reihenfolge. Und das zum Beispiel hier Informatik,
Uni Hamburg.de, das wäre die URL, die unser Fachbereich Informatik hat.
Und da sind wir drin, die SWK-Gruppe,
das ist dann haben wir unsere Forschungsgruppe, Softwareentwicklungs- und Konstruktionsmethoden,
hat man sich höher als Namen ausgedacht und uns gegeben.
Und da gibt es dann ein Paket drin. Für diesen Internetdomänen-Namen,
also Informatik, Uni Hamburg.de dreht man hier rum,
man fängt mit dem Größten an
Im Format, in die Hamburg.informatik. Und dann kommen vielleicht noch weitere Strukturspakete,
also Unterpakete, bis man zu dem Paket kommt,
wo dann wirklich der Quelltext drin ist,
beziehungsweise eine Klasse, hier die Klasse Box.
Und für das Dateisystem ist das hier ein Fall von Java
ganz einfach. Man dreht die Reihenfolge um zur natürlichen Reihenfolge,
die wir immer haben, also von und dran,
der Dormänennamen, zum Beispiel Informatik in die Hamburg.de,
dann SWK, dann Crafics und dann Box und dort finden sie auf einem lokalen Rechner,
die Namen.
Und damit haben wir gleich die Schachtelung,
Paket im Paket,
gut angegeben
Hier haben wir gleich ein bisschen den ersten Teil der Antwort auf die Frage.
Zwei erläutern sie die Eigenschaften von Paketen in Java.
Ja, also hier steht schon etwas dazu.
Wie ist denn das mit der Schachtel und wie ist das
mit den Namenskonventionen und wie ist das mit der Sichtbarkeit?
Dazu gehört auch noch, dass wir sagen, wie importieren
wir das? Tatsächlich Klassen sind ja genau solche Einheiten,
die etwas bereitstellen, was andere importieren können.
Und dazu gibt es
die Importanweisung
Und zwar können wir das einerseits so machen,
dass wir ein Paket importieren oder eine Klasse allein.
Also hier ein Beispiel, das Paket LMK wird von der Klasse
geimportiert oder nur die Klasse R von der Klasse, wie importiert.
Wir schauen uns an, wie das im Quelltext aussieht,
wenn wir hier ein ganzes Paket importieren,
dann steht LMK Import, die Import ist die Anweisung,
LMK.sternen, das heißt alle werden importiert und wenn wir nur R importieren,
dann würde mein Import df.r angeben
Das kann man in verkürzter oder in langer Form nach und machen.
Also wenn wir innerhalb des Pakets sind und es ist eindeutig,
dann wird mir einfach sagen, okay,
wir sind hier in Craphics drin oder man würde das,
dann kann man das verkürzen, insofern,
dass man nur für den Punkt spricht,
weil wir das vorher importiert haben.
Also das ganze Paket ist hier importiert worden,
hier im Beispiel von G würde man dein R direkt ansprechen können,
hier im Falschfall, wie haben wir das Beispiel,
wir importieren, dass die Klasse Craphic von der Klasse von Paketperfics,
die Klasse, Punkt.
Und dann brauchen wir nur noch sagen, okay,
so als wäre die Klasse im Paket drin,
wir geben das ohne Prefix ein
Man kann natürlich auch zugreifen auf etwas anderes Public,
ohne vorher importieren, zu vollen zu müssen.
Und da wurde man einfach dem Paketnamen davor angegeben,
also dieser Volk qualifizierte Namen. So,
das war auch noch etwas zu den Eigenschaften und nun zur Exportschnittstelle,
das ist das tatsächlich, was die Frage 3 von uns wissen will,
erläutern Sie Mechanismen des Zukunftsschutzes und der Sichtbarkeit,
das hat was mit Exportschnittstellen zu tun.
Die Exportschnittstelle ist erst mal implizit,
alles, was wir mit Public deklarieren,
ist nach außen sichtbar für den Export oder beziehungsweise für andere
zum Impact
Und wenn ich von außen zugreifen will,
wenn gar nichts dazu angegeben ist,
dass es also der Standardmodifikator, dann kann man das,
das haben wir eben schon kurz gesagt, nur innerhalb des Pakets zugreifen.
Und wenn es Public davor steht, kann ich außerhalb
überall zugreifen. Ja, und tatsächlich von allen Paketen,
es gibt keine Möglichkeit der Beschränkung hier. Diesen Zugriffsschutz,
das hat man bewusst nicht gemacht, dass man sagt,
okay, ich kann jetzt auf dieses Unterpaket nicht zugreifen.
Nein, ich kann immer zugreifen, wenn ich weiß,
wie das Ding heißt und wo es steht,
der volle Name reicht aus
und ich kann froh zugreifen
Allerdings muss man damit sagen, der Nachteil ist,
es gibt keine Entkopplung dadurch.
Ich kann nicht nur wieder ein Unterpaket verstecken. Das ist
gleichzeitig die Antwort auf die Frage ein, auf die Frage.
Vier, weil es ein Paket für andere Module sichtbar.
Es ist immer für andere Module sichtbar, wenn es denn irgendwie,
wenn man den Volk qualifizierten Namen angibt.
So,
damit sind wir schon bei dem Paket Zugriff und Sichtbarkeit