Hallo und herzlich willkommen zur fünften Vorlesung von Softwareentwicklung
2. Wie immer die Empfehlung, sich die Folien auszutrunken,
damit sie auf den Folien ihrer eigenen Hinweise machen können.
Ich sage auch ein bisschen die Foliennummern an,
damit sie auch zurück und vorspringen können, damit sie da nicht durcheinander kommen.
Wir haben heute ein relativ volles Programm und dieses volle Programm zeigt sich,
Moment, ich muss erst mal selber hier weiterspringen,
genau, also wir sind zunächst erst mal,
wir sind immer in dem Abschnitt,
wo es um Modularisieren geht und wir benutzen auch Hierarchien,
das Modularisieren vor allen Dingen im ersten Teil und dass Hierarchie in die Hierarchien im zweiten Teil und diese beiden Teile sehen sie auf dieser Übersichtsfolie.
Zunächst geht es um Module, dann um Fehler.
Und da möchte ich Sie gleich bei dem ersten Abschnitt,
wenn wir hier einsteigen, darauf hinweisen, Vorsicht,
hier gibt es jetzt einen Namen doppelt.
Ja, die Bezeichnung, wir können das nicht ganz verhindern.
Wir wollen ungern auf Modul als Strukturkonzept verzichten und dieses Modul
als Strukturkonzept kommt halt auch als Bezeichnung für ein Sprachelement vor.
Diese Warnung kommt dann, wenn wir da hinkommen,
gleich nochmal
Wir haben wieder die Fragen, zu denen wir kommen werden,
aber zunächst lassen Sie es erstmal wieder starten, Wiederholung, Modularität.
Ich betone das ein bisschen viel, weil das so ein Grundkonzept ist.
Das Grundkonzept hilft uns, große Systeme leicht änderbar zu halten,
indem wir Sachen zusammenfassen, die zusammenfassen können.
Und das sind Module. Dieses Prinzip der Bildung von großen Einheiten heißt im Englischen Junking,
also Dinge zusammenfassen, zu brocken, wenn sie so wollen.
Und der Sinn ist, wir wollen Komplexität besser beherrschen für unser Kurzzeitgerechnis,
für die Konsistenzsicherung, aber vor allen Dingen dafür,
dass Veränderungen, die an einer Stelle passieren,
sich nicht überall hinausbreiten, sondern möglichst begrenzt bleiben.
So, und in Hierarchien bilden sind Module ein ganz wichtiges Element.
Das heißt, wir versuchen in eine Hierarchie Module hineinzunehmen.
Dabei können Module selbst wieder Module enthalten und wir müssen versuchen zu regeln,
wie sind die Bezeichnungen und wir wollen dabei den Zugriff steuern.
Zugriff steuern, das ist genau das,
was wir auf der vorgehenden Folie ganz unten stehen hatten.
Wir wollen Änderungen begrenzen vom Aufwand her.
Und das machen wir über Zugriffssteuerung. Zunächst müssen wir sagen,
ja, wir haben einen Namensraum, das heißt,
wir haben die Möglichkeit, Namenskonflikte zu vermeiden,
indem wir einfach sagen, hier drin ist dieser Name eindeutig.
Und wenn da woanders nochmal vorkommt, ist es nicht so schlimm.
Und zumgleich dieser Schutz, dass wir Veränderungen nicht so weit ausbreiten lassen. Ja,
so das ist erstmal das ganz Grundsätzliche und das Geheimnisprinzip ist dabei das Übliche, ja,
wir versuchen, die Trennungen zwischen Schnittstelle und Implementierung zu haben,
ja, in den Java-Symbolen für Komponenten, die sehen so aus, dass man hier die Schnittstelle hat.
Insgesamt heißt, das ist die, bezeichnet dieses kleine Icon hier drin.
Es handelt sich nicht um eine Klasse, sondern um eine Komponente.
Und die Schnittstelle wird hiervon zugegriffen,
die von diesem Modul und das greift noch weitere zu
und die greifen auf das zu und die greifen auf das zu und benutzen,
kann nicht immer nur das, was durch die Schnittstelle freigegeben wird.
Die Interne, die Implementierung bleibt, versteckt und dieses Verstecken ermöglicht es,
dass sich hier innen drin mal eine Implementierung verbessern kann zum Beispiel ein Sicherheitsloch fixen,
eine Performance-Beschleunigung vornehmen oder was auch immer optimieren,
ohne dass die Schnittstelle betroffen ist und ohne dass ich dieses Modul dann ändern muss, geschweige denn noch dieses, was das aufruft.
Diese Steuerung wollen wir hier erreichen. So, das erste Konzept,
was wir da haben, sind natürlich die Klassen.
Java und Objektorientierung arbeitet mit Klassen, das sind die Elemente,
die die Typen definieren,
die den Bauplan für alle Exemplare bieten und die haben alle Eigenschaften von solchen Modulen.
Ja, sie sind logische Einheiten, sie sind,
sie definieren was sie nach außen geben, und zwar durch Public.
Und sie haben auch einen Namensrobben, den Namen Bezeichnern,
die ich da drin habe, sind durch die Zuordnung zur Klasse eindeutig.
Und was ich verbergen möchte, kann ich hier verbergen mit Private.
Und natürlich, es gibt auch die Möglichkeit,
dass Klassen wiederum Klassen enthalten, das ist ein bisschen weiterführend,
aber das ist schon mal ganz gut.
Dieses klassische Modulkonzept kann nicht so viel,
die Klassen können sogar noch mehr, wir können Typen definieren,
wir können Polymorphie machen und wir können hier eine Vererbungsbeziehung
Allgemeines und spezielles Mädelsmodulen machen
Das sind die Möglichkeiten und das ist auch gleichzeitig das,
was wir in der Frage 1 haben, nämlich die,
ich springe mal zurück zu der Frage,
Volye 4 ist das, wo die ganzen Fragen stehen.
Frage 1, was ist das Import bzw. Export-Interface einer Klasse?
Ja, auf dieser Folie steht immerhin, was das Export-Interface ist.
Das Export-Interface ist das, was wir in der Klasse Public haben.
Import-Interface steht hier nicht, aber Import kennen Sie als Schlüsselwort
von Java. Alles, was ich mit Import deklariere,
kann ich mehr, mache ich mir damit intern zugreifbar
Das kommt auf ein paar Folien später nochmal separat. Soweit erstmal zu den Klassen,
die, wir haben hier noch was Weiterführendes,
nämlich das ist mit der Hierarchie, geschachtelte Klassen,
innere Klassen, da gehe ich nicht weiter drauf ein,
dass es weiterführend ist.
Wir machen dann weiter im nächsten Video
mit Pakete