Herzlich willkommen zur zweiten Vorlesung, Softwareentwicklung 1. Heute geht es um Grundlagen von Objektorientierung.
Ich habe ja letzte Woche schon so einen Einstieg gegeben aus einem Anwendungsfall heraus,
dass man dann sich vorstellen kann, dass hinter einer,
unter einem Anwendungsfall wie ein Bankkunde geht zu seiner Bank und zieht Geld aus dem Automaten,
was da alles so passieren kann,
dass da Software hinter den Kulissen abläuft.
Da war natürlich ein sehr vereinfachter Blick auf die Welt,
aber einer, der so das grundlegende Verständnis für Objektorientierung
erstmal darstellen sollte
Und heute werden wir uns diese Begriffe alle ein bisschen genauer
ansehen, die im Kern die Objektorientierung ausmachen.
Letzte Woche haben wir noch so ein bisschen andere Paradigmen genannt.
Aber jetzt geht's wirklich in Medias Rehs. Bevor ich aber das mache,
dachte ich, wäre es vielleicht nicht schlecht,
wenn die nochmal ganz kurz zumindest wisst, wer denn hier vorne steht.
Das heißt, es ist eigentlich immer üblich,
dass ein Dozent sich auch zumindest kurz vorstellt.
Ich selbst habe Informatik studiert in Bremen. Und habe da
1993 meinen Abschluss gemacht. Dann bin ich nur kurz,
das ist hier gar nicht aufgeführt, bei einer Firma gewesen,
bei einem kleinen Start-up in Bremen, habe da ein halbes Jahr gearbeitet.
Und dann bin ich aber doch wieder an die Uni
War dann in Ulm mehrere Jahre tätig als, ja,
als Pimi und hab da auch Lehrveranstaltungen mit betreut, das Übliche.
Hab dann promoviert, 1999 über das Design von objektnotierten Programmiersprachen.
Dann war ich ein Jahr in Australien,
ich hatte ein Stipendium bekommen und die haben mir das dann finanziert,
dass ich ein Jahr in Melbourne arbeiten konnte an der Uni.
An der Monoshian University, die haben da mehrere Universitäten, genau wie Hamburg auch.
Und hab unter anderem im Blue Jack Team mitgearbeitet. Das heißt,
ich bin sozusagen ein Mensch der ersten Stunde,
der Blue Jay eingesetzt hat, als es gerade ganz frisch war,
1999,
ist also schon
ganz schön alt
Ja, es ist also wirklich, ja, fast jetzt zwölf Jahre alt,
schon fast pubertär jetzt. Dann bin ich zurück nach Deutschland,
habe noch mal so ein paar Monate in Ulm verbracht und bin dann
aber Anfang 2001 nach Hamburg gekommen und habe da so eine Doppelsituation gehabt,
habe also eine halbe Stelle an der Uni gehabt,
als wissenschaftlicher Assistent und eine halbe Stelle in der Firma von meinem Kollegen,
Heinz Zülichhofen, bei der C1-WPS,
die hieß damals noch ein bisschen anders und habe sozusagen zwei Jahre lang halb halb gemacht.
Das war ganz schön heftig. Für mich neue Stadt,
neue Jobs und nach zwei Jahren habe ich dann gesagt,
ich liege meinen Schwerpunkt doch stärker auf die Uni und bin deswegen seit 2003
hauptberuflich an der Uni und nur noch freiberuflich dann auch in der C1 WPS.
Da bin ich immer noch freundlich assoziiert.
Und seit erstem 6.2009 bin ich tatsächlich auf einer Dauerstelle,
juhu, akademischer Rat jetzt an der Uni Hamburg.
Meine Forschungsinteressen sind, kann Überraschung, Design,
Objekte und Titel, Programmiersprachen, weil ich darüber auch promoviert habe.
Das interessiert mich nach wie vor. Das wird auch so
hier so ein bisschen ab und zu mal durchschimmern,
dass ich da einiges zu sagen habe.
Dann habe ich hier in Hamburg agile Entwicklungsmethoden kennengelernt,
also eine Art und Weise, wie man Projekte durchführen kann,
die ich extrem spannend fand,
die auch die letzten zehn Jahre eigentlich die Welt der Softwaretechnik
ziemlich gerockt hat
Also zumindest mal vieles auf den Prüfstand gestellt hat, was vorher da war.
Dann das Thema Softwarearchitektur ist bei uns in dem Arbeitsbereich relativ ausgeprägt.
Ich bin da so schwerpunktmäßig mit Ausbildung beschäftigt.
Mich interessiert Ausbildung sehr gute Lehre. Und deswegen habe ich
auch einiges zu neuen Lehrkonzepten gemacht.
Also Objects First Ansatz, den wir auch hier praktizieren.
Ich habe auch dieses Buch von Barnes Calling übersetzt.
Der betreute Laborbetrieb ist bei uns jetzt hier eingeführt worden.
Die Teachlets sind etwas, was erst später kommt.
Das ist eine Art und Weise, wie man Code
anderen Menschen näher bringen kann und Entwurfsprobleme diskutieren kann.
Das ist eher was fürs dritte,
fünfte Semester
Okay, und Komplexitätsstufen von Objektsystemen in der Lehre,
das schimmert hier auch immer mal durch.
Ich habe ja auch schon so Anfang, so diese Levels vorgestellt letzte Woche,
nachdem wir hier unsere Inhalte ein bisschen strukturieren.
Gut, gibt es Fragen zu meiner Person, die noch
irgendwie relevant sind? So irgendwas, was ihr wissen wollt.
Okay, da habe ich mich vorgestellt, sehr schön.
Ich werde euch dann wahrscheinlich auch bald kennenlernen in den Übungen.
Einige kennen mich ja nun auch schon aus den Übungen.
Also heute geht es um Objektentierte Grundlagen. Das ist so die Übersicht,
das ist so grob die Planung bis zur Pause,
schaffen wir ungefähr die ersten Punkte und im zweiten Abschnitt
beschäftigen wir uns dann mal mit Das sind Definitionen,
also wie man wirklich eine Klassendefinition strukturiert aufbaut.
Aber am Anfang machen wir noch mal so ein paar ganz grundlegende Dinge, die Objektorientierung betreffen.
Ich habe diese Folge letzte Woche schon gezeigt und ich zeige sie,
glaube ich, am liebsten jedes Mal zukünftig,
weil ich immer wieder merke, dass das so etwas ist,
was so banal daherkommt, aber doch immer wieder gern vergessen wird.
Nämlich, dass es in der Objektorientierung,
wenn wir ein Objektorientiertesystem haben,
in dem sehr viele Objekte miteinander zusammenarbeiten,
dass es ständig
dieses Verhältnis gibt zwischen einem Klient und einem Dienstleister
Es ist immer so, dass ein Objekt bei einem anderen Objekt eine Dienstleistung in Anspruch nimmt.
Das muss aber nicht nur zwischen Objekten sein. Wenn ihr euch BlueJ anseht,
das habt ihr jetzt in der ersten Woche schon kennengelernt,
dann ist es so,
ich kann hier ein Exemplar erzeugen, der Klassikkreis,
das habt ihr auch schon gemacht und kann jetzt hier Methoden an diesem Exemplar aufrufen.
Das hier ist sozusagen ein einzelnes Objekt und an diesem Objekt
kann ich jetzt irgendwas aufrufen.
Ich bin jetzt in diesem Moment ein interaktiver Klient.
Das ist etwas, was BlueJ ermöglicht,
dass man ein beliebiges Objekt hernehmen kann und damit interagieren kann,
also etwas an diesem Objekt aufrufen kann.
Das ist, wie gesagt, eine Spezialität von Blue Jay.
Und es ist aber auch ein Beispiel für eine Klientenbeziehung.
Wir sind dann in dem Moment interaktive Klienten.
Dieses Objektes. Okay, und die Idee ist,
dass das Dienstleistungen sind, die uns da angeboten werden?
Das ist auch tatsächlich so gemeint.
Also diese Dienstleistungen tauchen an der Schnittstelle auf. Das,
was hier in Blue Jay auftaucht, das ist eigentlich die Schnittstelle.
Haben wir in der ersten Woche schon in den Übungen so
ein bisschen besprochen. Also die Summe der Methoden,
die sie bildet,
jetzt erstmal so als erste Näherung
Schnittstelle eines Objektes. Okay, also diese Dienstleistungen werden als Methoden angeboten.
Tatsächlich, also jede Methode idealerweise eine Dienstleistung. Und dann gibt es Klienten,
die das anfordern können und das nennen wir die Schnittstelle.
War alles schon letzte Woche dran. Und der Anbieter kann
selbst wieder Teile seiner Dienstleistung von anderen Dienstleistern einholen.
Das ist natürlich auch tatsächlich hier der Fall. Ist es
hier tatsächlich die Situation, dass ich sagen kann bei einem Kreis,
hey, mach dich mal erstmal sichtbar.
Dienstleistung oder dann wird hier irgendwo diese kleine Leinwand aufgepoppt und
dann hat sich dieser Kreis, dieses Exemplar hier,
hat sich selbst sichtbar gemacht.
Also man Man muss eigentlich sagen, dieses Objekt hat sich gezeichnet auf der Leinwand.
Und das geht dadurch, dass Kreis hier irgendwo eine Benutztbeziehung hat.
Also diese Pfeile sind benutzt Beziehungen, zur Leinwand hat.
Das heißt, damit der Kreis sich selbst zeichnen kann,
muss er erstmal wieder selbst die Dienstleistung von einem anderen Objekt in Anspruch nehmen,
nämlich an der Leinwand, die dann anbietet,
dass man da was drauf zeichnen kann.
Das ist also tatsächlich auch genau das,
was wir hier jetzt auf der Folie haben,
dass ein Dienstleister auch selbst wieder ein Klient sein kann.
Und das führt dazu,
dass wir ständig diesen Wechsel haben zwischen,
wir müssen aus der Sicht eines Klienten denken und wir müssen
aus der Sicht eines Dienstleisters denken
Und das macht es ein bisschen schwierig manchmal, das klarzukriegen.
Warum ist das so ein Unterschied? Man könnte jetzt sagen,
boah, das ist ein Objekt,
das liefert da Dienstleistung und das ist halt irgendwie implementiert.
Das wird es halt irgendwie machen. Die Dinge sind sehr,
sehr unterschiedlich. Wenn ihr euch das hier anguckt, Blu-Jay,
ihr fandet das vermutlich in der ersten Woche ganz angenehm,
dass man hier relativ einfach diese Schnittstelle benutzen konnte.
Also es ist relativ verständlich, was da passiert.
Wenn so ein Kreis erstmal sichtbar ist,
dann kann ich den jetzt irgendwie horizontal bewegen.
Das ist also sehr einfach. Dass da einiges an Programmierungen
dahinter steckt, dass das wirklich passiert,
ist euch
wahrscheinlich auch klar
Und dass ihr erstmal noch keine Ahnung habt,
wie das genau passiert. Das Schöne ist,
bei dieser Objektorientierung, man hat diese Sicht auf ein Objekt,
dass es einem eine Dienstleistung bringt.
Und ich muss mir nicht Gedanken darüber machen, wie das umgesetzt ist.
Es ist höchstens wichtig, was passiert da?
Was passiert, wenn ich jetzt aufrufe, horizontal bewegen?
Das möchte ich natürlich verstehen. Aber wie das gemacht ist
, ist zweitrangig. Und wir abstrahieren also sehr gerne,
wenn wir Klient sind, davon, wie eine Dienstleistung erbracht wird.
Und das ist im Kern der Objektorientierung.
Wenn wir uns Objekte dann näher ansehen, dann verteilen wir
gerne nochmal zwei ganz zentrale Aspekte. Nämlich zum einen,
dass sie ein Verhalten zeigen und dass sie einen Zustand haben.
Ihr habt das jetzt auch schon gesehen in Blue Jay.
Ich kann zum Beispiel bei diesem Objekt jetzt hier,
diesem Kreisobjekt, das sich auf dieser Leinwand hier dargestellt hat,
da kann ich jetzt Operationen aufrufen.
Das heißt, ich kann jetzt hier das Verhalten irgendwie steuern.
Ich kann sagen, Mensch, jetzt beweg dich doch mal irgendwie nach rechts.
So, und dann bewegt dich das ein Stück nach rechts,
damit ich das nochmal aufrufe, nochmal nach rechts,
dann taucht das da auch so ein bisschen dahinter auf.
Außerdem haben wir aber auch gesehen, dass so ein Objekt ja auch einen Zustand hat.
Man kann in BlueJay diesen Objektinspektor öffnen, das heißt,
hier sieht man jetzt eine Darstellung der Zustandsfelder eines Objektes.
Also dieses sind ja so Slots,
wo dann Informationen gehalten sind über den Zustand des Objektes.
Und dieser Zustand wird auch geändert. Wenn ich jetzt hier etwas mache,
also wenn ich jetzt hier zum Beispiel sage,
Kreis bewegt dich doch mal nach rechts, dann seht ihr,
die Exposition ist jetzt 60 und die Y-Position ist auch 60 in diesem Objektinspektor.
Und wenn ich jetzt nach Rechtsbewegung aufrufe, dann ist
die X-Position jetzt 80, weil die sich geändert hat.
Das heißt, dieser Zustand hat sich geändert.
Ich habe eine Dienstleistung aufgerufen, dadurch hat sich
der Zustand des Objektes geändert
Okay. Idealerweise ist halt dieser Zustand mehr oder weniger verborgen.
Das heißt, wir haben so eine abstrakte Idee davon,
dass dieses Objekt einen Zustand hat und wir rufen halt diese Methoden auf.
Das heißt, wie es gemacht ist,
ist es üblicherweise verborgen und das ist auch gut so.
Das verringert die Komplexität, dass man nicht verstehen muss,
wie alles im Einzelnen gebaut ist. Dass Dinge von einem Zustand abhängig sind,
kann man sich auch an diesem Kontobeispiel überlegen,
was ja hier auch auf der Folie so ein bisschen angedeutet ist.
Hier ist also mal so ein Objektdiagramm angedeutet,
also wir haben ja ein Exemplar,
der klassische Girokonto und da gibt es sowas wie,
ist Auszahlen möglich,
bei einem Konto kann man sich das fragen,
ist das Auszahlen wirklich möglich oder möchte man
wirklich einen bestimmten Betrag auszahlen
Und dann ist vermutlich so,
dass bei diesem Konto intern irgendwie der Zustand gehalten ist,
zum Beispiel der Saldo, also der aktuelle Kontostand,
und vielleicht noch der Dispo bei dem Girokonto.
So, und das sind Informationen, die zum Zustand gehören.
Und es ist auch interessant, dass natürlich verschiedene Exemplare,
verschiedene Zustände haben können. Verschiedene Konten können verschiedenen Saldo haben, hoffentlich,
wird er doof, wenn alle den gleichen Kontostand hätten.
Oder vielleicht wäre es auch nicht so doof, es wäre eigentlich ganz cool.
Oder das Dispo, das kann natürlich auch sehr unterschiedlich sein. Und klar,
mal kann man auszahlen und mal kann man nicht auszahlen,
wenn das Konto gerade nicht gedeckt ist,
dann wird es vermutlich nicht auszahlbar sein.
Okay, Was ich auch ganz gerne immer darstelle,
ist diese Sicht auf ein Objekt,
nämlich der Zustand ist so irgendwie in der Mitte und umklammert von den Methoden.
Das heißt, wir haben sozusagen die Methoden als etwas,
was die Schnittstelle nach außen darstellt,
also so ein Objekt kann man sich wirklich wie so ein ovales Bubblechen vorstellen.
Und jemand, der von außen etwas machen will,
muss eine Methode aufrufen. Sollte üblicherweise nicht direkt irgendwie auf
die Zustandsfelder zugreifen, auf diese Dinger da in der Mitte.
Sondern letztendlich sind das immer Dienstleistungen, die über die Methoden
aufrufbar sind. Okay, also Verhalten ist in den Methoden
Wenn wir uns gleich noch ein bisschen genauer angucken,
wie denn da das Verhalten implementiert ist in diesen Methoden?
Also ganz viele Methoden und in der Mitte ein Zustandsfelder.
Das kann nur eins sein, kann auch gar keins sein.
Die werden gleich auch ein Beispiel sehen,
wo wir gar keinen Zustand haben bei einem Objekt,
wo es einfach nur ein Verhalten zeigt. Und dann,
wenn wir jetzt einen Methodenaufruf haben durch einen Klienten,
wir haben also jetzt wieder noch die Sichtweise, ah,
da ist ein Objekt und ein anderes Objekt ruft dieses Objekt auf.
Also hier so ein Aufruf, Kontrollfluss. Ihr erinnert euch irgendwie,
jetzt sind wir gerade in diesem Objekt. Das Objekt,
was jetzt hier in der Mitte so sichtbar ist, wird zum aktuellen Objekt.
In diesem Objekt werden jetzt in der Methode Anweisungen ausgeführt.
Und jetzt haben wir tatsächlich plötzlich die Sicht gewechselt auf das Objekt.
Eben haben wir noch gesagt, das ist das Objekt in
der Außensicht und ich kann es als Klient benutzen.
Und jetzt gucken wir im nächsten Moment rein und sagen,
aha, jetzt sind wir drin im Objekt und jetzt gucken wir mal genauer,
was passiert denn da?
Nämlich, dass in einer Methode Anweisungen sequenziell ausgeführt werden.
Und das ist halt wieder der Kontrollfluss, den ihr auch
schon gesehen habt. Jetzt wird das ausgeführt und am Ende,
wenn die Methode beendet ist, wird wieder zum Aufrufer zurückgesprungen.
Und ganz wichtig ist halt, das ist genau das,
was wir sequenzielle Ausführungen nennen,
das beinhaltet dann alles,
was zur imperativen Programmierung gehört
Und imperative Programmierung ist wirklich, das sind nicht nur Anweisungen,
sondern diese Anweisungen sind dann teilweise zusammengesetzt aus Zuweisungen
oder aus Ausdrücken oder aus Prozeduraufrufen, aufrufen.
All diese Dinge. Und da werden dann primitive Typen verwendet
, Basistypen von Java. All das Zeug werden wir uns
in den nächsten Wochen ansehen. Ja,
also wir sind jetzt immer noch so ein bisschen am Runterzoomen
von diesem Anwendungsfall mit den Bankkunden immer näher ran an die Objekte.
Jetzt gucken wir schon in die Objekte rein und sehen,
aha, in den Methoden werden Operationen ausgeführt.
Und das ist tatsächlich das, wo dann sich möglicherweise auch Algorithmen abspielen.
Also die Lösungsbeschreibungen, die wir gleich uns nochmal ein bisschen angucken.
Ich will das hier nochmal demonstrieren. Deswegen nehmen wir jetzt
einfach mal hier dieses Exemplar weg. Entfernen dieses Exemplar.
Und hier seht ihr jetzt eine Klasse Zeichner. Das ist ein Projekt,
das ihr in dieser Woche auch in den Übungen vor die Nase bekommt.
Das ist eigentlich das gleiche Projekt wie das, was ihr schon kennt.
Bis auf diese neue Klasse. Diese neue Klasse nennt sich
Zeichner. Und wenn ihr da mal reinguckt,
was wir hier gerade tun, dann sieht man hier,
Klaas Zeichner,
und dann sieht man hier letztendlich
nur eine Methode
Die ist relativ lang und das ist die Methode.
Also hat diese Klasse eine Methode und sie hat keine Zustandsfelder.
Also das ist tatsächlich so im Sinne dieser Folie hier,
ist das hier irgendwie ziemlich klein? Das hat eigentlich,
man hat eigentlich hier nur Methoden oder eigentlich sogar nur eine Methode.
So, und um das einfach mal deutlich zu machen,
dass das tatsächlich so zu einer sequentiellen Ausführung kommt,
gibt es ganz wunderbare Möglichkeiten, sich das in Blue Jay mal anzeigen zu lassen.
Ich kann zum Beispiel hier einen Haltepunkt setzen,
das ist relativ leicht,
ich kriege da einfach hin auf diese linke Leiste und dann sagt das
so viel wie wenn an dieser Stelle jetzt irgendwann mal die Ausführung vorbeikommt,
wenn also der Kontrollfluss vorbeikommt,
der rote Faden,
dann soll da
bitte angehalten werden
Habe ich jetzt hier reingesetzt, diesen Haltepunkt.
Und jetzt bin ich hier in Blue Jay,
jetzt kann ich hier nochmal eben diese Leinwand,
die kann ich eigentlich mal eben schließen.
So, und jetzt kann ich hier bei dem Zeichner erstmal
ein Exemplar erzeugen. Ich kann von einer Klasse,
auch wenn sie keine Zustandsvariablen hat, keinen Zustand hat,
keinen Zustand definiert für ihre Exemplare,
kann ich natürlich trotzdem ein Exemplar erzeugen.
Ich kann auch zwei Exemplare erzeugen. Die würden sich natürlich
nicht in ihrem Zustand unterscheiden, weil sie ja keinen Zustand haben.
Aber sie haben ein Verhalten. Das heißt,
sie bieten uns Dienstleistungen an, zum Beispiel zeichne.
Deswegen heißt die Klasse auch Zeichner,
das ist halt eine Klasse, die zeichnet einfach irgendwas auf
diese Leinwand
Ja, das heißt, das,
was ihr letzte Woche interaktiv gemacht habt, das heißt,
ihr habt Exemplare von diesen Klassen erzeugt und die dann
irgendwie verschoben und farbig gemacht und so weiter.
Das ist jetzt hier einfach mal ausprogrammiert. Und das ist ein ganz wichtiger Sprung,
dass ihr sozusagen von dieser interaktiven Benutzung von Objekten hinkommt zu,
naja, ihr sollt es programmieren.
Er soll wirklich Programmcode hinschreiben, der das macht.
Wenn ich jetzt jetzt hier aufrufe, diese Operation,
diese Methode zeichne, dann erscheint hier ein Debugger-Fenster.
Und das ermöglicht mir dann, dass ich jetzt hier tatsächlich
schrittweise durch diesen Quelltext durchgehen kann.
Also hier sehen wir zum Beispiel jetzt New Quadrat,
das habt ihr ja auch schon gemacht,
das ist jetzt gelb markiert,
das heißt,
diese Zeile ist
noch nicht ausgeführt
Wenn ich da jetzt auf Schritt klicke hier und in diesem Debugger-Fenster,
dann wird diese Operation ausgeführt. Da kann man noch nicht viel sehen.
Aber jetzt beim nächsten Schritt steht der Wand, sichtbar machen.
Jetzt wird also dieses Objekt, dieses Quadrat,
was wir gerade erzeugt haben, sichtbar,
es müsste also jetzt auf der Leinwand erscheinen.
So, jetzt hoffe ich mal,
dass hier die Leinwand erscheint oder isst sie auch.
So, wunderbar. Dann kann ich die mal hier so
ein bisschen zur Seite schieben, dass man das besser sehen kann.
So, und jetzt mache ich hier einfach weiter.
Ein weiterer Schritt, die Farbe ändern gelb,
ist schon passiert, vertikal bewegen.
Dann geht es ein bisschen nach unten. Dann ändere ich
noch die Größe und dann machen wir das Gleiche weiter mit dem Quadrat.
Da kommt das nächste Quadrat,
das wird sichtbar gemacht
Wird gebläut. So ein bisschen nach rechts bewegt und es wird nach unten bewegt.
Also man kann hier sehr schön sehen, wie man schrittweise
diese Anweisungen innerhalb des Rumpfes einer Methode kontrolliert ausführen kann.
Das geht in Blue Jay sehr schön mit dem Debugger.
Ich kann es jetzt auch hier einfach mit fortsetzen, einfach zu Ende machen lassen.
Und was man aber auch hier schon mal sieht,
was auch eine Rolle spielen wird, ist, dass hier lokale Variablen auftauchen.
Also wenn ich jetzt hier nochmal das Dreieck irgendwie da drauf setze,
das Dach, so jetzt kommt noch die Sonne dazu,
Dann sehen wir tatsächlich, jetzt haben wir hier vier lokale Variablen,
die letztendlich Objektreferenzen sind.
Wir sehen uns Objektreferenzen noch nicht genauer an.
Das müsst ihr erst mal jetzt hier so hinnehmen,
dass das hier passiert. Uns geht es eher darum,
dass tatsächlich innerhalb dieser Methode jetzt hier lokale Variablen stehen.
Und dass die wirklich nur innerhalb dieser Methode eine Rolle spielen,
also nur während der Ausführung von der Methode zeichnen, sind diese Variablen sichtbar.
So, wenn ich jetzt also hier sage fortsetzen,
dann wird erstens die Sonne noch so ein bisschen bewegt,
das sieht man hier, also da steht dann irgendwie Sonne sichtbar machen,
Farbe ändern rot, vertikal bewegen und dann langsam horizontal bewegen.
Wenn ich das jetzt mal einfach ausführe, Dann sieht man auch,
dass dann hinterher die ganzen lokalen Varianten abgeräumt sind,
weil diese Methode eigentlich fertig ist.
So, tolle Animationen. Habt ihr mal gesehen,
das ist also mehr oder weniger das,
was in so einer Methode abläuft oder ablaufen kann.
Und was wir jetzt uns noch mal ein bisschen angucken wollen,
sind so ein paar Grundbegriffe, die, wie gesagt,
in den nächsten Wochen noch mal genauer beleuchtet werden.
Eine wichtige Sache ist, wieder sekleinen Beziehungen, Objekte interagieren,
indem Objekte, Klienten, Methoden an anderen Objekten aufrufen.
Also wir haben dieses Beispiel gehabt in diesem Szenario mit dem EC-Automat,
der jetzt irgendwie bei dem Girokonto irgendwie Ja,
Geld abheben möchte und erstmal nachfragt, wie ist das überhaupt möglich?
Ruft also auf, ist Auszahlen möglich, 300 Euro.
Der möchte also da vielleicht gerade 300 Euro auszahlen lassen.
Und dann kann es sein, dass diese Methode eben halt hier ein Parameter hat.
Das mit dem Parameter habt ihr auch schon gesehen,
ihr konntet die Farbe zum Beispiel angeben, da gibt man als Parameter an,
in welcher Farbe das denn geändert werden soll.
Hier also zum Beispiel 300 Euro.
Und diese 300 Euro sind ein aktueller Parameter.
Der Begriff aktueller Parameter ist eine dieser Heldentaten der deutschen Informatiker,
weil das ist die Übersetzung des englischen Action Paramita.
Und wenn ihr mal Englisch gelernt habt, dann wisst ihr,
dass actual nicht aktuell heißt. Sondern actual heißt tatsächlich.
Das heißt, das sind die tatsächlichen Parameter. Also irgendjemand,
ein Klient, ruft etwas auf und übergibt einen echten Wert.
Und das ist dann ein tatsächlicher Parameter. Und wie gesagt,
irgendein Held hat da mal aktuelle Parameter draus gemacht und seitdem
steht in sämtlichen Lehrbüchern der Informatik in Deutsch aktueller Parameter.
Müssen wir bei uns mit abfinden, werden wir auch,
da werden wir nicht gegen angehen.
Gegen andere Begriffe sind wir so ein bisschen anders drauf,
aber das muss man einfach so hinnehmen.
Das ist einfach etabliert, altehrwürdig
Auf der anderen Seite, bei dem Dienstleister,
und jetzt kommt wieder sozusagen die Innensicht des Dienstleisters,
wenn wir jetzt beim Girokonto reingucken, wie der denn gebaut ist,
dann sehen wir, der definiert hier einen Betrag.
Das heißt, man muss, wenn man dieses Ist-Auszahlen möglich aufrufen will, einen Betrag angeben.
Und für die Methode, die da aufgerufen wird,
ist das dann ein formaler Parameter. Und witzig ist natürlich,
aktuelle Parameter können ganz unterschiedliche benutzt werden,
unterschiedliche Klienten geben unterschiedliche Werte an,
aber hier wird davon abstrahiert, da wird einfach nur gesagt,
na gut, wenn ich aufgerufen werde,
dann wird mir irgendeinen Betrag gegeben.
So, und dann ist das erstmal eine Variable und die
wird dann hier tatsächlich mit diesem Wert belegt
Gut, jetzt kann der hier ein Ergebnis zurückgeben.
Jetzt kann dieser Girokonto als Dienstleister sagen, ja, ist möglich.
Also liefert True zurück. Also ist Auszahlen möglich,
seht ihr hier, hat unter anderem diesen Rückgabewert Bulien.
Und das heißt, es kann einen Wahrheitswert zurückgegeben werden,
True oder Falls. In diesem Fall wird hier anscheinend True zurückgeliefert.
Also kann jetzt der EC-Automat im nächsten Schritt sagen,
dann zahl doch mal 300 Euro aus.
Okay, diese Werte, diese Begriffe aktueller Parameter formaler Parameter
werden wir uns nochmal genauer angucken in der nächsten Woche,
wenn wir über Prozeduraufrufe reden.
Weil das ist hier letztendlich nichts weiter als ein Prozeduraufruf,
nur in der Objektorientierung sind es halt Methoden
Diese Prozeduren. Okay, der Begriff einer Signatur,
der ist euch auch schon über den Weg gelaufen in der ersten Übung.
Da stand es auf dem ersten Aufgaben bei gleichem Einleitungstext drauf.
Das ist so eine unserer kleinen Fingerübungen,
dass wir gleich mal so ein bisschen, sagen wir,
eine sperrige Definition eines Begriffs hernehmen und dann mal sehen,
ob ihr schon sozusagen in der Übung seid,
sowas zu lesen und es dann auch direkt anzuwenden auf das,
was ihr dann vor euch seht.
Da war ich in meinen Übungen sehr positiv überrascht,
dass das tatsächlich von den meisten einfach tatsächlich gelesen worden ist und verstanden worden ist.
Ich habe das einfach in den Jahren vorher auch schon anders gehabt,
dass man dann sagt, ja,
hier diese Methode,
was ist denn
die Signatur
Und dann startet man so in zwei leere Augen,
die überhaupt nicht wissen, was die Signatur ist.
Und dann sage ich, naja, hast du vielleicht mal den Anleitungstext gelesen?
Alles super dieses Jahr. Also ich bin total begeistert.
Kann natürlich auch jetzt einfach Glück sein, dass ich eine gute Übungsgruppe habe.
Keine Ahnung. Auf jeden Fall ist das wieder jetzt
ganz wichtig. Ist ja auch ein bisschen rot hervorgekommen,
weil es im Skript nicht drin steht.
Die Signatur ist das, was für einen Klienten relevant ist.
Also wenn ich eine Methode aufrufen will,
dann muss der Klient ja wissen, welchen Typ haben die Parameter?
Wie heißt die Methode überhaupt? Das sind die zentralen Informationen
. Und das ist dann eben so,
dass wenn man so den Kopf einer Methode hernimmt,
auf den Begriff kommen wir gleich noch
Dann ist eben halt nicht alles,
was im Kopf steht, auch wirklich Teil der Signatur.
Gut, das nur so als formaler Begriff. Jetzt haben wir
die ganze Zeit über Objekte gesprochen. Das war auch ganz gut so,
weil wir reden ja über Objektorientierung, die Objekte,
die man sich so vorstellen kann,
die in so einem Objektorientierten System miteinander zusammenarbeiten,
werden ja irgendwann mal erzeugt.
Und wir gehen auch dann nachher nochmal so ein bisschen genauer darauf ein,
wie denn Objekte erzeugt werden. Ganz wichtig ist aber,
dass das, was wir hier machen,
nämlich Objekte und Teleprogrammierung mit Java,
dass da für jedes Objekt immer eine Klasse existiert.
Und eine Klasse ist tatsächlich sowas wie eine Schablone oder eine
Blaupause oder ein Bauplan. Vielleicht am besten ein Bauplan.
Der Begriff ist eigentlich am griffigsten. Die Klasse ist ein
Bauplan für ihre Exemplare. Und wir bezeichnen wirklich die Objekte,
die man so mit so einer Klasse erzeugen kann als Exemplare.
Das heißt, auch hier wieder in Blue Jay,
ich mache mal den Debugger zu, den brauchen wir jetzt erstmal nicht mehr.
Kann ich auch mal den Zeichner schließen.
Kann auch hier vielleicht noch das Objekt entfernen.
Kann auch vielleicht noch dieses Fenster zumachen. So,
wenn ich jetzt hier ein Kreisexemplar erzeuge, Dann habe ich das hier liegen.
Das hat dann einen Zustand. Und ich kann aber natürlich
von dieser Klasse auch einfach zwei Exemplare erzeugen.
Und das hat dann auch einen Zustand. Und ich kann tatsächlich
diese Zustände unabhängig voneinander manipulieren. Ich kann also jetzt hier
nach rechts bewegen, aufrufen und nochmal nach rechts bewegen.
Und dann hat das hier eben halt einen anderen Zustand als dieses Objekt.
Beides sind aber Exemplare der Klasse. Und das bleiben sie
auch. Das ist tatsächlich in der Objektorientierung mit Java,
ganz zentral, so auch mit den meisten Objekte und jutten Programmiersprachen,
die ihr so kennenlernen werdet in eurem zukünftigen Leben
Projekte bleiben Exemplare ihrer Klasse. Selten können Objekte ihre Klassenzurückheit ändern.
Und so eine Klassenzugehörigkeit sagt auch ziemlich viel über das Objekt
aus. Also die grundlegenden Eigenschaften, das ganze Verhalten,
also die Methoden, sind ja in der Klasse festgelegt.
Der Zustand kann geändert werden, aber auch,
da kann nicht irgendein beliebiger Zustand entstehen,
sondern alles nur im Rahmen dessen, was diese Klasse erlaubt.
Also wenn die Klasse sagt, das Ding hat fünf Zustandsfelder,
sieht man hier fünf Zustandsfelder,
dann kannst du nicht plötzlich ein Objekt geben dieser Klasse,
das sechs Zustandsfelder hat.
Wird nicht passieren. Es sei denn,
man ändert die Klasse
Da ist also ein ganz enger Zusammenhang zwischen den Klassen und
ihren Exemplaren. Klasse definitiv, also das prinzipielle Verhalten.
Es können beliebig viele Exemplare erzeugt werden. Und jedes Objekt
hat aber eine eigene Identität, einen eigenen Zustand.
Und man kann auch unterschiedlich auf Anfragen reagieren, je nach
dem Zustand, weil der Zustand ja unterschiedlich sein kann.
Okay, was wir jetzt schon mal so grundsätzlich gesehen haben,
ist Objekte interagieren in den Objekten, stecken Methoden drin,
die dann irgendwie auf dem Zustand arbeiten, auf diesen Zustandsfeldern.
Was wir jetzt hier in SE1 intensiv machen werden, ist,
programmieren im Kleinen. Das heißt, wir werden Zum einen
imperative Grundlagen diskutieren. Das heißt, was weiß ich,
Umsetzung eines Algorithmus, also eines Lösungsrezeptes in ein lauffähiges Programm.
Und zum Programm steht aus Anweisungen. Das war klassisch die
Sicht auf Programmierung in der imperativen Programmierung ist das so.
Programm besteht aus Anweisungen, die letztendlich irgendeinen Algorithmus umsetzen.
Das ist auch ein zentrales Thema hier,
da machen wir relativ viel zu,
aber inzwischen ist es eben halt auch so,
wenn man mit einer Objektnotiertensprache arbeitet,
dass man dann auch einfach mit Klassen und Methoden umgeht
Und das ist auch etwas, was wir hier ganz zentral tun.
Was wir nicht betrachten werden, ist, wenn ja jetzt irgendwie 20,
100, 5000 Klassen zusammenkommen und ein großes System bilden.
Die meisten seriösen Java-Systeme sind deutlich größer als das,
was wir in SE1 hier machen werden.
Das heißt, das bleibt alles sehr klein. Unsere Projekte werden
sehr klein bleiben. Wir werden immer so höchstens fünf Klassen
irgendwie gleichzeitig in einem Projekt in Bluejay sehen im ersten Semester.
Programmieren im Großen ist eben halt dann deutlich mehr größere Projekte,
größere Teams, die gemeinsam daran arbeiten und so weiter,
Softwarearchitektur, so ein Voreindruck geben wir dann schon in SE2 darauf.
Also dieser Algorithmusbegriff, den wollen wir jetzt mal ein bisschen
näher beleuchten, aber noch nicht so richtig intensiv.
Es gibt ja auch für die meisten von euch eine Veranstaltung,
Algorithmen und Datenstrukturen, da wird dann der Algorithmusbegriff nochmal richtig schön fundiert, aufgearbeitet.
Wir vermitteln hier eher so ein intuitives Verständnis und sagen halt,
naja, wenn wir sowas haben wie das hier,
das nehmen wir mal an, sei ein Algorithmus.
Das ist tatsächlich etwas, was Programmiersprachen unabhängig ist und es soll irgendwie,
ja, ich vermute mal, das Maximum Zweier natürlicher Zahlen liefern.
Also da wird er diese zwei Zahlen,
diese zwei natürlichen Zahlen A und B vergleichen,
wenn A größer als B ist, dann setzt er das Ergebnis,
magst du gleich den Wert von, ah,
sonst setzt er das ja jedes Max gleich den Wert von
So, das ist etwas, was,
sagen wir relativ gut nachvollziehbar ist, dass das eine Lösungsbeschreibung dafür ist,
wie man das Maximum zweier ganzer Zahlen oder zwei natürlicher Zahlen ermittelt.
Wenn man das ein bisschen auswerten, dann sehen wir,
so ein Algorithmus besteht irgendwie immer aus Aktionen,
die halt üblicherweise auch sequenziell ausgeführt werden,
beziehungsweise es gibt dann die Möglichkeit von Wiederholungen,
kommen wir erst später zu.
Also hier sind solche Aktionen zum Beispiel sowas wie Vergleiche oder Sätze, den Wert einer Variablen.
Und hier die Aktion bezieht sich irgendwie auf Variablen,
in diesem Fall zumindest, ja, also A,
B, Max, die durch diese Aktion gegebenenfalls verändert werden.
Also ganz wichtig, Variablen haben einen Zustand eine Belegung.
Aufpassen die jetzt, Variablen sind was anderes als Objekte.
Variablen sind Konzepte in der imperativen Programmierung, die in den Objekten irgendwie drinstecken.
Nur um das gut abzugrenzen, da gehen wir aber noch genauer drauf ein.
So, und jede Variablen ist auch ein Typzugang.
Also wir reden hier jetzt zum Beispiel von natürlichen Zahlen und wir gehen mal davon aus,
dass wenn A und B natürliche Zahlen sind,
dass dann auch Max vermutlich eine natürliche Zahl sein wird.
Über die Frage des Typs von solchen Varianten werden wir
auch nochmal ein bisschen sprechen
Was also letztendlich in den Rümpfen von Methoden passiert ist, imperative Programmierung.
Das heißt, Folgen von Anweisungen, habe ich schon angedeutet,
die Ausführungsreihenfolge ist auch durch die textuelle Reihenfolge vorgeben.
Das ist nicht in allen Programmiersprachen so. Also die logischen
und funktionalen Programmiersprachen, da hat die Reihenfolge die Reihenfolge,
wie das da im Text steht,
nicht unbedingt das damit zu tun, wie da was ausgeführt wird.
Bei der imperativen Programmierung ist es fast immer so,
dass man sieht, naja,
wenn die Anweisung unter der anderen steht,
dann wird sie
auch nach dieser Anweisung ausgeführt
Da gibt es so höhere Programmkonstrukte, die dann Anweisungsfolgen zusammenfassen.
Zum Beispiel Prozeduraufrufe sind dadurch dann ein wichtiger Mechanismus, um Anweisungsfolgen zusammenzufassen.
Werden wir dann auch noch nächste Woche sehen.
Und benannte Variablen können Werte annehmen. Das haben wir,
wenn wir uns auch noch intensiver angucken.
Das alles basiert auf dem Vernäumern-Konzept, also auf dem von Neumann-Rechner.
Das ist eine Art und Weise, auf Rechner drauf zu schauen.
Die meisten euch bekannten Rechner sind nach dem von Neumann-Prinzip gebaut.
Wir gehen dann auch noch mal ein bisschen darauf ein,
in den nächsten Wochen, was das denn eigentlich heißt.
Aber letztendlich ist es so, wir haben einen Computer,
der hat einen Speicher, auf diesem Speicher können irgendwelche Veränderungen vorgenommen werden,
indem man irgendwelche Befehle ausführt.
Und dann werden Belegungen im Speicher geändert.
Also mehr oder weniger Abstraktionsstufe über dem Computer.
Während logischer und funktionale Programmierung von der anderen Seite kommt,
dass sie Kalküle haben oder Formalismen und dann sozusagen das irgendwie abbilden auf den Computer.
Hier ist es so, in der imperativen Programmierung,
wir haben die Maschine und wir abstrahieren über bestimmte Eigenschaften dieser Maschine.
Okay, dann gibt es Ablaufsteuerung durch Kontrollstrukturen,
Kontrollstrukturen ist auch etwas, was wir uns noch näher ansehen werden.
Dann gibt es zum einen die Sequenz,
die haben wir jetzt schon gesehen, sequenzielle Ausführungen.
Da gibt es außerdem noch die Fallunterscheidung, die wiederholen.
Das sind so die drei zentralen Kontrollstrukturen. Die Sequenz habt
ihr jetzt schon gesehen, ist nicht so spannend,
eine Anweisung nach der anderen, hebt den Hörer ab.
Also wenn wir zum Beispiel sowas hier,
den Algorithmus telefonieren nehmen, informell, hebt den Hörer ab,
will die Telefonnummer für das Gespräch, legt den Hörer auf.
Sehr einfach, nachvollziehbar. Fallunterscheidung, ist da ein bisschen
was anderes? Irgendein Telefon klingelt?
Fallunterscheidungen werden wir uns auch so bald mal angucken.
Das wird jetzt in den Übungen dieser Woche noch keine große Rolle spielen,
aber es ist natürlich so, dass ihr, wenn ihr irgendwelche Dinge programmiert,
relativ schnell sowas brauchen werdet, wie eine Fallunterscheidung.
Also wenn eine Bedingung zutrifft, dann für das eine aus, ansonsten für was anderes aus. Das ist hier in Java angedeutet,
wenn A-Klein-AP ist, dann ist Minimum gleich A, A,
Minimum ist gleich B oder eben halt hier beim Telefonieren,
ich habe den Hörer ab, wenn die Telefonnummer gespeichert ist,
dann drücke die Kurzwahltaste, ansonsten werdet ihr die Telefonnummer,
wenn der Gesprächspartner antwortet, dann führt das Gespräch,
ansonsten legt den Hörer wieder auf und natürlich auch wieder auf den,
ja,
da ist eine Frage
Befriedigende Erfahrung, wie das, wenn er mit den zwei Kernen noch damit ist.
Ja, das ist eine sehr gute Frage. Er fragt,
warum hier ein Wenn mit den zwei Sternchen steht. Das ist,
glaube ich, einfach noch ein Relikt aus uralten Folientagen,
als diese Folie noch in ganz anderen Veranstaltungen aufgetaucht war.
Es gibt Sprachen, da ist das sozusagen üblich,
dass man am Ende der Bedingungen dann auch nochmal sagt,
wo gehört denn das Ende dazu?
Also dieses Ende gehört zu dem, wenn. Und dieses Ende gehört zu dem,
wenn, wenn die jetzt verschachtelt sind, dann ist das manchmal ganz nützlich,
dann noch irgendwie zu sagen, zu wem das dann gehört.
Es gibt Sprachen, da ist das üblich,
in Java macht man das nicht, da steht ja auch kein Ende,
sondern in Java steht dann eben halt hier so eine geschweifte Klammer.
Dafür gibt es dann andere Konventionen, um deutlich zu machen,
was wozu gehört in, insbesondere die Einrückung ist sehr, sehr wichtig.
Bei Java-Programmierung. Okay, dann kommt noch die Wiederholung,
das machen wir erst ab Woche 5,
werden wir uns hier intensiv mit Schleifen beschäftigen,
wie man dann auf Basis einer logischen Bedingung immer wieder eine Schleifenrumpf durchführt,
bis eine Bedingung nicht mehr zutrifft, zum Beispiel.
Okay, das sind erstmal nur so kleine Ausblicke und was
wir aber uns nochmal ansehen werden, sind die imperativen Variablen,
weil ihr jetzt auch ja schon in diesem Beispiel hier gesehen habt,
das ist die Klasse, die ihr auch in dieser Woche bearbeiten werdet.
Da ist es tatsächlich so, da sind hier in der Methode Zeichne.
Das ist ja auch in Blue Jay ganz schön gemacht,
dass man hier auch so genau sieht.
Also das ganze Grüne hier ist ja die Klasse.
Das ist die ganze Klasse. In der Klasse drin ist
dann die Methode Zeichne und die ist hier so gelb hervorgehoben
und man sieht genau, wo die Methode sich überall befindet.
Und innerhalb dieser Methode ist dann der Rumpf der Methode,
man sieht dann hier unter anderem Deklarationen von Variablen
Und diese Variablen werdet ihr auch benutzen in dieser Woche.
Und ihr werdet dann eben sehen, dass Variablen durchaus auch
ihre Belegung ändern können. Das wird jetzt in diesem Beispiel
hier mit dem Zeichner nicht so der Fall sein,
aber in den folgenden Wochen wird das noch passieren.
Ganz wichtig, so eine Variable ist tatsächlich erstmal eine Abstraktion
eines physischen Speicherplatzes. Also im Rechner gibt es Speicherplätze und
so eine Variable steht für so einen Speicherplatz.
Grob gesagt. Und es ist klar,
dass man in so einen Speicherplatz unterschiedliche Werte reinspeichern kann.
Das heißt, die Belegung einer Variablen kann sich ändern.
Das ist ganz zentral. Das ist ein
völlig anderer variablen Begriff als in der Mathematik
Muss man sehr aufpassen. Viele Leute,
die so mathematisch fundiert sind, haben da so ein bisschen
Probleme mit mit diesem Zustandskonzept von Variablen in der imperativen Programmierung.
Also kann man sich so wirklich so eine Variable,
wie so ein Behälter vorstellen, in dem was reingetan wird.
Also hier ist zum Beispiel so eine Veranschaulichung,
so ein Behälter, so ein Pfefferstreuer, so ein Pfefferglas.
Und da kann man eben halt viel Pfeffer drin haben oder wenig Pfeffer.
Aber es sollte irgendwie dann doch immer der Typ Pfeffer eingehalten werden.
Wenn Pfeffer draufsteht, dass auch Pfeffer drin ist.
Wenn ihr dann Chili drin habt,
dann kann das manchmal unangenehme Überraschungen geben
Oder es ist Salz drin und man haut so viel und so weiter.
Klar, also man möchte schon, dass das irgendwie vom Typ passt.
So ähnlich ist es mit den Variablen in der Programmierung auch,
wenn hier eine Variable, den Typ Zahl hat,
ganze Zahl oder Intager wie in Java, dann würde man erwarten,
dass man da auch nur Zahlen drin ablegen kann.
Aber natürlich abhängig von dem Lauf des Programmes kann die Variable
mal den einen Wert und mal den anderen Wert speichern.
Genau. Und das ist auch ganz wichtig,
in den Sprachen, die wir hier uns ansehen,
ist es eigentlich so, dass Variablen immer deklariert werden müssen,
bevor man sie verwenden kann.
Auch das sieht man hier in diesem Beispiel
Hier haben wir vier Variablen, nämlich Wand, Fenster,
Dach und Sonne und die werden hier benutzt.
Wenn ich jetzt mal mir das erlaube hier,
diese Variable auszukommentieren und das versuche zu übersetzen,
dann wird der Compiler meckern und wird sagen, naja,
hier unten, da wird ja Wand einfach benutzt,
aber ich weiß gar nicht, was wann ist.
Also wenn ich jetzt das übersetze, dann sagt der,
Kennot Fine Symbol, variable Wand. Der Compiler meckert,
wenn eine Variable benutzt wird, die nicht deklariert wurde.
Also Variablen müssen immer deklariert werden. Ich kann hier also
ein BlueJay sehr schön mit F7 und F8 einkommentieren
Auskommentieren. Toll. Toll, toll, toll.
Eine tolle Idee. Ja, also das kann ich jetzt
wieder übersetzen und jetzt müsste es auch wieder übersetzbar sein.
Genau. Was also erstmal so die imperativen Grundlagen,
also Variablen müssen deklariert werden. Außerdem müssen sie auch initialisiert
werden. Es ist tatsächlich so lokale Variablen wie hier.
Die müssen irgendwann initialisiert werden, bevor sie benutzt werden können.
Also in diesem Fall sieht man zum Beispiel hier Wand,
kriegt hier etwas zugewiesen, nämlich eine Referenz auf ein Quadratobjekt.
Und dann kann man erst mit Wand was aufrufen.
Dann kann ich erst Wandpunkt sichtbar machen, aufrufen.
Das ist tatsächlich Deshalb möglich, weil es erst initialisiert wurde.
Der Compiler meckert auch, wenn ihr so eine Variable zwar deklariert, aber nicht initialisiert.
Auch das ist denkbar. Ich kann, glaube ich,
jetzt hier auch mal, machen wir das doch mal,
kommentieren wir mal diese Zeile aus. Jetzt müsste der Compiler eigentlich sagen,
du hast wann zwar deklariert und du machst jetzt hier auch was mit Wand,
aber ich bin mir ziemlich sicher, dass die Variable noch nicht initalisiert ist.
Ich hoffe mal, dass das jetzt zutrifft,
was ich sage, dass ich hier nicht irgendwie, ja,
und genau das kommt dann auch als Fehlermeldung, Variable,
wann might not have been initialized, ist möglicherweise nicht initialisiert worden.
Klar, wunderbar, das sind so Eigenschaften von Sprachen wie Java,
dass sie Zwar sagen wir ziemlich viel fordern.
Viele finden das lästig, dass ich von einer Variablen
jetzt erst deklarieren muss, welchen Typ hat sie denn?
Gibt auch andere Sprachen, wo man das nicht tun muss.
Ja, stimmt. Aber der Vorteil ist,
wenn ich dann was falsch mache,
klopft mir der Compiler auf die Finger und weist mich auf Situationen hin,
wo vielleicht was nicht ganz stimmt.
Meistens hat der Compiler da auch recht. Es gibt Situationen
fortgeschrittener Programmierung, wo man möglicherweise durch diese Regeln,
dass man alles deklarieren muss und explizit machen muss,
etwas eingeschränkt ist. Aber der Mehrwert, der entsteht,
dass man eben halt große Systeme dadurch wartbehält, ist relativ unschätzbar.
Okay, ich werde hier nochmal eben wieder
das einkommentieren
Ja, ich habe die Frage gesehen.
Ich komme gleich dazu. Ja. Wir haben einen gegeben
. So, jetzt mit meiner Wichtigkeit. Ah,
okay, die Frage ist, was würde denn passieren,
wenn ich an dieser Stelle hier bei vertikal bewegen nicht einen Integer angebe?
Also hier gebe ich ja tatsächlich einen Literal an,
also eine ganze Zahl direkt als Wert. Was wäre,
wenn ich da jetzt angebe, das war, glaube ich,
die Idee, dass ich jetzt hier zum Beispiel gelb angebe.
Sowas war die Idee, ne
So, ja, das ist eine wunderbare Idee für die Übung.
Könnt ihr ja mal selber in den Übungen machen.
Ich werde es jetzt hier nicht machen,
damit ihr ein bisschen neugierig seid, was passiert.
Na gut, okay, ich mache es jetzt mal.
Vertikal bewegen Int in Quadrat, Cannot Be Apply to Java Langstring.
Also hier wird ein String übergeben und er sagt,
ich habe hier nur ein Vertikal bewegen mit einem Int und deswegen
passt das nicht zueinander.
Also auch da gibt es eine Fehlermeldung. So,
jetzt fragt er, was machen wir denn,
wenn wir bei Farbe ändern, einen Intager-Wert angeben?
Dann wird eine ähnliche Fehlermeldung kommen. Ich glaube,
das führt jetzt zu weit, das sollten wir jetzt nicht
zu weit treiben.
Das könnt ihr auch wunderbar an den Übungen selbst ausprobieren.
Dafür sind die Übungen übrigens auch da
Gibt es noch weitere Fragen? Da ist noch eine.
Könnt ihr ein bisschen leise sein? Ich verstehe ihn ganz
schlecht. In dem Verein. Ihr müsst uns melden,
ich schreibe zum Beispiel, wenn ich Vater sollen,
kriegt es den Vater über uns gar nicht.
Ich dachte, das ist nicht der Vater.
Ich habe die Frage nicht ganz verstanden. Also ich glaube,
hier geht es darum, hier ist die variable Wand vom Typ Quadrat.
Und jetzt muss ich ja hier hinschreiben, New Quadrat.
Und warum das notwendig ist, ist das die Frage?
Das war, auf jeden Fall Quadrat,
das war ein Weg
Hinter Quadrat, das Wand weglassen, das ist die Frage.
Nee, nee, das ist tatsächlich, hier wird eine Variable deklariert.
Das ist eine Grundregel. Und diese Variable kann dann verwendet werden.
Und wenn sie nicht deklariert ist, kann sie nicht verwendet werden.
Und sie muss halt dann auch entsprechend initialisiert werden,
wie das in diesem Fall der Fall ist.
Gut, da ist noch eine Frage. Da programmiert sie
das Alter, das mache ich auch in den komplizierten Sachen.
Es gibt nichts zu misserliches. Er fragt,
wäre es schlechter Programmierstil, wenn man eine Variable von einem primitiven Typ,
haben wir noch gar nicht behandelt, kommt noch.
Also das sind ja jetzt hier Objekttypen, ja,
also Quadrat, Dreieck und so weiter sind Objekttypen.
Wenn wir jetzt sowas hätten wie einen Integer,
also eine Variable vom Typ Int.
Und wir würden die nicht initialisieren, ob das ein schlechter Programmierstil wäre.
Auch das könnten wir jetzt hier live machen.
Auch das ist was, was ich in den Übungen machen könnte.
Es ist tatsächlich so eine lokale Variable. Egal von einem
primitiven oder einem Referenztyp. Wenn die nicht initialisiert wird,
meckert der Compiler. Lokale Variablen haben keine Default-Werte.
Ihr müsst sie initialisieren. Es gibt andere Variablen,
die Exemplar-Variablen,
auf die wir heute auch noch zu sprechen kommen,
die haben Standardbelegungen
Und da ist es eigentlich guter Stil, sie zu initialisieren.
Also explizit zu machen, dass sie mit einer Belegung belegt werden,
die auch dann deutlich kommuniziert, was sie machen.
Das werden wir gleich heute Mittag gleich in der zweiten Hälfte
noch mal uns ein bisschen genauer angucken.
Okay, da ist noch eine Frage. Die Frage ist,
ob es möglich ist, eine Variablen einer Zeile gleicht,
also gleichzeitig zu deklarieren und auch zu initialisieren.
Und hier ist ein Beispiel dafür. Genau das ist möglich
. Hier wird die Variable I vom Typ Int deklariert und
sie wird auch gleich initialisiert
Und das ist tatsächlich eine Initialisierung,
das ist etwas anderes, als was hier ist.
Hier wird die Variable deklariert und dann wird hier eine Zuweisung gemacht.
Und das hier sieht zwar genauso aus,
aber wenn bei der Deklaration, das da steht,
ist es eine Initialisierung der Variablen und ansonsten ist es einfach hier eine Zuweisung.
Das sind jetzt schon so Details,
da müssen wir vielleicht nicht jetzt ganz so drauf einsteigen.
Gut, wenn es nicht nur Fragen gibt,
dann haben wir jetzt das Zwischenfazit erreicht und können dann jetzt
mal eben fünf Minuten Pause machen.
Dann würde ich euch bitten,
wieder zur Ruhe
zu kommen
Damit die ich weitermachen kann. Vielen Dank. Okay. Also,
was wir jetzt gesehen haben, nochmal zur Wiederholung,
Objekt haben wir einen Zustand und bieten Dienstleistungen an.
Das sind diese beiden zentralen Begriffe, Zustand und Dienstleistungen.
Und die Dienstleistungen werden in Form von Methoden angeboten.
Also das Verhalten in Methoden. Der Zustand wird in Zustandsfeldern gehalten.
Die Zustandsfelder gucken wir uns gleich mal ein bisschen genauer an.
Die Aufrufbaren Methoden bilden die Schnittstelleklassen,
sind Schablonen zur Erzeugung von Exemplaren
Innerhalb einer Methode werden Anweisungen sequenziell ausgeführt. Die Anweisungen werden
nach den Prinzipien von Kontrollstrukturen ausgeführt, also Sequenzfallunterscheidung, Wiederholung.
Und dann gibt es eben halt ganz zentral den Begriff von Variablen,
die ihre Belegung dynamisch ändern können, dynamisch heißt,
während der Ausführung des Programmes können sie mal den einen oder anderen Wert enthalten.
Das ist zentral für die imperative Programmierung.
So, jetzt machen wir mal einen kleinen Bruch.
Also was heißt einen kleinen Bruch? Wir machen ein
anderes Projekt. Bis jetzt haben wir dieses Figurenprojekt gesehen.
Jetzt werde ich mal ein anderes Beispiel hernehmen,
weil dieses Figurenprojekt ist ganz hübsch,
weil ihr bei den Objektklassen hier seht, dass sie einen Zustand haben.
Man kann diesen Zustand sozusagen direkt sehen. Ach,
jetzt habe ich hier noch diesen Fehler drin, den müssen
wir eben wieder rausnehmen. So. Dass diese Objekte einzogen.
Wir haben den aber noch gar nicht uns genau angeguckt.
Also wir haben zweimal mit dem Objektinspektor reingeguckt,
aber wir haben noch nicht gesehen, wie die gebaut sind.
Das ist auch Absicht, dass diese Klassen hier,
wenn man den Doppelklick macht,
dass man da nicht allzu viel zu sehen bekommt,
nämlich nur sozusagen die Sichtweise, die für einen Klienten interessant ist.
Man sieht hier, man kann da oben auswählen zwischen
Quelltext und Dokumentation
Und das ist hier mit Absicht, dass wir gesagt haben,
naja, diese Klassen sollt ihr eigentlich nur benutzen,
ihr sollt nur die Schnittstellensicht zu sehen bekommen.
Ich werde jetzt mal ein Projekt öffnen,
das ein bisschen anders gestrickt ist, sehr viel einfacher.
Nämlich dieses Projekt Girokonten. Und das enthält nur eine Klasse, nämlich eine Klasse Girokonto.
Und das sei jetzt mal unsere erste selbstgeschriebene Klassendefinition.
Also in der nächsten Woche werdet ihr dann in den Übungen
auch mal tatsächlich eine Klasse von Grund aufschreiben.
Hier ist es jetzt noch so in der zweiten Woche,
das, was ihr in der ersten Woche interaktiv gemacht habt,
macht die jetzt so ein bisschen in der Programmierung und werdet einfach nur innerhalb einer Methode ein bisschen was,
was ändern, erweitern und so weiter.
Aber nicht sehr viel und eigene richtige Klasse schreibt ihr dann
erst in der dritten Woche. So, nehmen wir mal an,
wir haben jetzt hier so eine klasse Girokonto.
Das passt ja ganz gut zu diesem Anfangsszenario.
Ja, sieht erstmal gut aus. Tolle Klasse.
Das ist auch genau das, was man hier sieht.
Wenn man hier dieses Girokonto öffnet, dann sieht das genauso aus.
Also Klausirokonto, private in unterstrich Saldo und dann Public Void einzahlen.
Was das jetzt für eine Struktur hat,
werden wir uns dann gleich nochmal genauer angucken
Das ist also das, was man hier zu sehen bekommt.
Und was für uns erstmal wichtig ist,
wenn ihr ein Java-Programm schreibt, dann besteht das aus Textdateien.
Das heißt also, letztendlich ist das jetzt das erste Mal,
dass ihr in den Übungen auch selbst mal solche Dinger bearbeitet.
Das heißt, ihr habt dann auch Kontakt mit einem Editor.
Also das hier ist ein Editor, also ein Werkzeug,
einer Entwicklungsumgebung, das euch ermöglicht, Texte zu bearbeiten.
Ist kein Hexenwerk, habt ihr wahrscheinlich alle schon irgendwie mal benutzt,
ob ihr jetzt Word benutzt habt oder irgendwelche anderen Editoren.
Das sind halt, das ist Software, mit der man Texte bearbeiten kann.
Es ist extrem nützlich, wenn man vernünftig programmieren lernen will,
schnell mit einem Editor umgehen zu können.
Das ist so was, was ich immer am Rande ganz gern erwähne.
Also wenn ich jetzt hier zum Beispiel irgendwie zwei Zahlen selektieren will,
dann kann ich das mit der Tastatur sehr schnell machen.
Man kann das auch mit der Maus so ganz vorsichtig irgendwie da so rüberziehen und fürchterlich.
Also mit der Tastatur kann man fast alles viel schneller machen.
Es ist auch hilfreich, wenn ihr mal Tastaturkurs gemacht habt,
also irgendwie mal Schreibmaschine gelernt habt, zehn Finger schreiben oder so.
Das ist ganz erstaunlich, dass einfach die Leute, die das,
die nicht sozusagen bei jeder Taste auf die Tastatur starren müssen,
um da irgendwas reinzutippen,
sondern tatsächlich einfach live coden können
Schreiben können und auf dem Bildschirm lesen können,
das hilft unheimlich. Also werdet flüssig mit einer Tastatur.
Das ist extrem nützlich, wenn ihr programmieren wollt.
Und mit diesem Editor könnt ihr eben halt dann diese Klassendefinition bearbeiten.
Das ist ganz wichtig. Das, was man hier in
dem Diagramm sieht, ist die Klasse Girokonto.
Von dieser Klasse kann ich Exemplare erzeugen und so weiter,
lala. Aber das hier ist die Klassendefinition.
Also hier wird sozusagen im Quelltext definiert,
wie die Klasse aussieht und wie dann auch natürlich die Exemplare aussehen.
Das heißt, ein Java-Programm besteht erstmal aus solchen Packs-Dateien
Das ist jetzt hier noch kein wichtiges Programm, weil wenn
man ganz ehrlich ist, ist das hier relativ armselig.
Hier ist einfach nur ein Girokonto. Davon kann man irgendwie
mehrere Exemplare erzeugen. Da passiert noch nicht viel.
Also von einem Programm zu sprechen ist hier Quatsch.
Sondern es ist eben halt bei Java-Programmen so,
dass sie halt aus Klassen bestehen. So,
und in jeder dieser Textdateien ist halt üblicherweise eine Klasse beschrieben,
mindestens eine Klasse, es kann manchmal auch mehr sein.
Und das nennen wir eine Klassendefinition und bearbeiten sie mal im Editor.
Sehr schön. Wenn wir jetzt diese allererste Klasse uns mal genauer angucken,
dann sehen wir halt generell Java-Programme stehen aus Klassen,
also hier Girokonto.
Die Klasse definiert eine Methode
Das sieht man auch hier in Blue Jay ganz gut.
Dieses gelb hervorgehobene ist hier die Methode. Methode einzahlen. Okay,
ich kann ja auch mal hier mal ganz banal so ein Exemplar erzeugen.
Hier Girokonto, juhu. Und dann habe ich tatsächlich hier
so ein Girokonto. Und das sieht relativ langweilig aus,
hat einen Saldo. Das kann ich hier auf dieses Konto
was einzahlen, kann also irgendwie 100 Eier einzahlen.
Und dann habe ich eben halt da 100 drauf.
Ja, und ich kann noch mehr einzahlen. Und ihr
seht schon, dass es kein besonders attraktives Konto ist.
Man kann nur einzahlen. Würde ich nicht nehmen bei
der Bank.
Da sind Fragen dazu
Ah, okay, da kommt der schlaue Einwand.
Man kann da auch Minusbeträge angeben. Das ist richtig.
Ich könnte jetzt natürlich hier tatsächlich sagen, ich gebe jetzt
hier an minus 100, um das mal zu tun.
Und das führt tatsächlich dazu, dass der es wieder gesenkt wird.
Das habe ich hier sozusagen durch die Hintertür ein Abheben eingehoben, eingeführt.
Völlig schrecklich, bitte auf keinen Fall als Beispiel nehmen jetzt.
Es ist nur so, dass momentan dieses Girokonto noch
sehr einfach gestrickt ist. Zukünftig würde man dann sagen,
naja, als Parameter gibt man da üblicherweise einen Betrag an
und Beträge werden dann garantiert nur positiv sein
Und dass man hier jetzt als Int den Parameter-Typ gewählt hat,
ist der Vereinfachung geschuldet. Vernünftigerweise programmiert man das mit einem Werttyp,
also zum Beispiel Betrag. Aber das ist fortgeschrittenes Zeug,
aber die Anwerkung ist richtig,
also ihr seht aber hier erst mal,
ich kann hier jetzt natürlich auch von diesem Ding jetzt noch ein Girokonto erzeugen,
wunderbar, dann habe ich hier gleich zwei davon.
Und das hat halt auch einen Zustand und das
ist alles ganz entzückend. Dann die Methode,
er hält einen Parameter, haben wir auch gesehen,
ich muss einen Wert angeben hier vom Typ Int und hat keinen Rückgabewert.
Dass sie keinen Rückgabewert hat, sieht man daran,
dass hier Ähm, da, da, hier steht Void.
Kein Rückgabetyp. Dass so Methoden auch Rückgabetypen haben,
werden wir uns gleich nochmal ansehen. Okay, ist da irgendwo
eine Meldung? Nee, das schnipst du gerade so.
Im Rumpf der Methode wird ein Wert, einem Zustandsfeld zuwiesen.
So, jetzt haben wir das erste Mal hier ein Zustandsfeld.
Ich habe eben gesagt, bei dem Zeichner, der hatte keinen eigenen Zustand.
Da gab es keine Zustandsfelder. Das ist jetzt hier eine Klasse,
da haben die Exemplare ein Zustandsfeld,
nämlich genau den Saldo,
den Kontostand des Kontos
Der wird jetzt zum Beispiel hier in einer solchen Methode,
die da aufgerufen wird, verändert.
Also hier wird jetzt irgendwie gesagt, Saldo ist gleich Saldo
plus Betrag. Es ist schon eine relativ anspruchsvolle Zeile,
die da steht, weil da steht relativ viel Zeug.
Also steht mal hier erstmal, Saldo wird irgendwie ausgelesen.
Der Wert, der in Saldo gespeichert ist,
wird addiert mit dem Betrag, der da irgendwie als Parameter übergeben wurde.
Und das Ergebnis wird dann wieder gespeichert in dem Behälter Saldo.
Also in dem Zustandsfeld. Also wird an dem Konto dieser Zustand
geändert. So, so ein Feld muss natürlich deklariert sein
, haben wir auch hier gesehen.
Das ist ja hier deklariert und es ist vom Typ Int
und es hat den Unternamen unterstrich Saldo.
Wir nennen Exemplarvariablen
Also Felder nennen wir die Dinger in den Objekten.
Also das hier zum Beispiel, in diesem kleinen Girokonto hier, in diesem Objekt.
Das nennen wir ein Feld. Man sieht ein Objekt,
da ist ein Feld drin und das ist dann tatsächlich etwas,
was zur Laufzeit relevant ist, wenn das Programm irgendwann mal läuft.
In der Klassendefinition nennen wir die Definition davon, eine Exemplarvariable.
Weil es sich so ziemlich ähnlich verhält wie eine normale Variable.
Also wir haben hier vorhin gesehen, die lokalen Variablen.
Jetzt haben wir hier einen formalen Parameter und hier haben wir
jetzt so eine Exemplarvariable. Alles drei Arten von Variablen mit
unterschiedlichen Eigenschaften, die wir uns noch genauer ansehen.
Also das nur
Zustandsfeld, Exemplarvariable, ist eigentlich synonym, bezeichnet das Gleiche.
Das eine ist eher so die Betonung, das Objekt,
wenn es dann irgendwie da ist, dann hat es ein Feld.
Und in der Klassendefinition nennen wir Dinge halt Zustandsexemplarvariablen. Okay,
so Prinzipien der Objektorientierung, naja, was haben wir da so?
Das Verhalten ist halt definiert. Wir haben wieder gesagt,
ja, das Verhalten, klar, Dienstleistungen, Methoden.
Also hier ist eine Dienstleistung nämlich einzahlen.
Es kann eine sehr reichhaltige, aber immerhin. Dadurch,
dass es public ist, ist es für Klienten aufrufbar.
Das ist wieder was, was wir sehen müssen,
dass mit der Schlüsselwort Public gesagt wird.
Diese Methode gehört zur Schnittstelle dieser Klasse. Wir werden gleich sehen,
dass das auch anders aussehen kann. Zum Beispiel ist es
ja so, dass diese Exemplarvariable hier, die ist ja private.
Und Private heißt so viel wie nur innerhalb dieser Klassendefinition sichtbar und zugreifbar.
Also ein Klient kann da nicht einfach von außen jetzt dieser Variablen
was zuweisen, weil sie sozusagen gekapselt ist in der Klasse.
Also auch dann hier die Umsetzung dieser Dienstleistung einzahlen ist halt hier so ein bisschen gekapselt.
Man kann sich das auch so angucken, dass man hier sieht,
dass bei dieser Klasse Wenn ich dir jetzt hier so auch mache,
im Quelltext sieht man jetzt tatsächlich,
wie ist das Ding aufgebaut oder wie ist der Quelltext strukturiert?
Können wir ja auch die Dokumentation anzeigen lassen. Selbst von
dieser einfachen Klasse kann ich mir die Dokumentation generieren lassen.
Und dann sieht man hier, da gibt es nur die Methode Einzahl.
Also das ist jetzt die Sicht für einen Klienten.
Wir aufpassen ein Klient, will das Ding benutzen,
der will nur wissen, was das Einzahlen macht.
Idealerweise wäre das jetzt auch kommentiert, was diese Methode da macht.
Da ist eine Frage. Er fragt,
ob die Dokumentation in Bluejay automatisch erstellt wird.
Nein, sie wird erstellt in dem Moment,
wo man hier auf Dokumentation klickt.
Also Bluejay macht das für einen
tatsächlich,
Das ist also eine nette Leistung von Blue Jay,
dass man für eine einzelne Klasse sich diese Dokumentationssicht anzeigen lassen kann.
Und will dann auch noch lernen, dass man das auch vernünftigerweise,
so kommentiert das dann auch in dieser Schnittstellenansicht,
die Informationen gegeben werden, die ein Klient braucht,
um die Methode sinnvoll nutzen zu können.
Man sollte ja immer irgendwie erläutern, was die Methode denn tut.
Gut, Zustandsfelder, interne Struktur gekapselt,
Saldo ist privat und ich kann also sozusagen nur diese Dienstleistungen aufrufen,
indem ich dieses Einzahlen aufrufe.
So, dann nochmal die Gruppstruktur einer Klassendefinition
Das nennen wir den Kopf einer Klasse, also das hier sozusagen den Schnittstellenkommentar der Klasse.
Man sollte eigentlich immer irgendwie einen Kommentar stehen haben,
der sagt, wofür ist diese Klasse eigentlich gut?
Was soll diese Klasse eigentlich im Gesamtkontext des Java-Programms?
Das ist so ein spezielle Kommentarform, die dann auch wieder dazu führt,
dass dieser Kommentar in die Dokumentation aufgenommen wird. So,
und dann haben wir den Rumpf der Klasse,
das ist eigentlich alles das, was nach dieser Zeile mit dem Glasschlüsselwort steht,
also von der Öffnen bis zu dieser schließenden Klammer,
das ist der Rumpf der Klasse.
Und da drin befinden sich halt alle diese Bestandteile,
die wir uns jetzt genau angucken,
nämlich Exemplarvariablen
Konstruktoren und Methoden. Okay, also hier nochmal so ein
bisschen angedeutet. Klasse, ja, es sieht so aus,
dann hat man hier irgendwie die Felder oder die Exemplarvariablen.
Konstruktoren und Methoden. Und man sieht ja,
diese Klasse hat keinen Konstruktor. Ist das wirklich so?
Nein, es ist nicht so. Diese Klasse hat einen
Konstruktor. Das ist wieder eine Spezialregel von Java,
wenn kein Konstruktor dasteht, dann wird implizit einer erzeugt.
Das heißt, ich kann tatsächlich ja hier aufrufen, New Girokonto.
Das kann ich nur, weil ein Konstruktor da ist.
Der wird also sozusagen automatisch generiert von Java
Wenn ich nicht selber einen schreibe. Wir werden jetzt mal
einen schreiben, damit wir das mal deutlich machen,
damit wir es explizit machen.
Das heißt, ich schreibe jetzt hier einfach mal ein Konstrukt da rein.
Und zwar sage ich hier Public, Girokonto.
Und dann... Nur bin ich bescheuert? Nee.
So. Das ist ein Konstruktor. Ein Konstruktor heißt immer genauso
wie die Klasse
Er hat keinen Rückgabe-Typ, also es gibt hier keinen Void oder so oder irgendwas ähnliches.
Und das definiert, was passiert, wenn ein Objekt neu erzeugt wird.
Nämlich da soll zum Beispiel jetzt mal gesagt werden, Saldo soll gleich null sein.
Und da sind wir jetzt genau an dem Punkt,
wo eben die Frage kam, ist es denn nicht so,
dass zum Beispiel hier so ein primitiver Typ,
also eine Variable, eines primitiven Typs vom Intiar,
die ist vorbelegt mit dem Wert null.
Das heißt, Java definiert für Exemplarvariablen für jeden Typ
einen Default-Wert,
eine Standardwert
Bei Int ist es null, bei Boolion ist es Falls und so weiter.
Und man könnte sich jetzt darauf verlassen, dass das hier passiert.
Und es ist auch so, das wird immer passieren.
Java-Programme sind in der Hinsicht sehr eindeutig.
Aber es ist auch nicht so schlecht, hier zu sagen,
naja, explizit, wenn ein neues Konto angelegt wird,
dann hat das erst mal einen Anfang, Saldo von null.
Da steht da wirklich, man kann es lesen.
Es ist also ein Teil der Dokumentation. Das andere ist
implizites Wissen. Genau wie das da gar kein Konstrukt da
eben stand und trotzdem einer da war. Ihr werdet,
wenn ihr in der Praxis mit Objektnotierten Sprachen arbeitet,
natürlich dann oft die Dinge gerne annehmen, wo der Compiler euch Vereinfachung erlaubt.
Für das Programmieren, Lernen ist es aber sicherlich erst mal sinnvoll.
An der Stelle jetzt hier So ein Konstrukt der Expliziten zu schreiben.
Da oben ist eine Frage. Das ist auch mal
die Sanierung von Maria. Ja, die Frage ist,
was ist der Unterschied oder macht es einen Unterschied,
wenn ich jetzt hier im Konstruktor die Exemplarvariable initialisiere oder
ob ich das Gleiche oben bei der Deklaration mache?
Ich kann das ja auch hierhin schreiben. Auch da wieder
von den Quelltextkonventionen her sagen wir, es ist eigentlich sauberer,
das im Konstruktor zu machen und nicht da.
Es ist nur eine Frage des Zeitpunktes
Also das, was ich eben gemacht habe,
das wird zuerst gemacht und anschließend wird dann der Konstruktor ausgeführt.
Das ist also kein großer Unterschied. Da ist noch eine
Frage. Aber man muss es gar nicht dazu behauen.
Aber er fragt, ob man, man muss nicht einen Konstruktor haben.
Nein, es ist, sagen wir mal so,
eine sinnvolle Klasse hat einen Konstruktor.
Wenn man keinen hinschreibt, dann ist automatisch ein parameterloser Konstruktor da.
Das haben wir auch eben gesehen. Man sollte aber eigentlich
immer einen Konstruktor schreiben, weil häufig möchte man ja auch
Diese Erzeugung eines neuen Objektes, eines Exemplares, steuern können.
Wir können uns zum Beispiel vorstellen, dass wir hier sagen,
dass sich hier ein Parameter einführe, Anfang Saldo.
Das heißt, wenn dein Konto angelegt wird, kann man
direkt beim Erzeugen angeben, wie viel es schon drauf ist.
Also ich eröffne ein Konto bei einer Bank und sage gleich,
hier sind meine 5000 Euro, die ich da gleich mal draufpacken will.
So, ja, dann ist es tatsächlich so, jetzt wird das hier übersetzt.
Es ist tatsächlich okay. Wenn ich jetzt ein Exemplar erzeuge,
dann muss ich hier einen Parameter angeben.
Und dann kann ich jetzt hier sagen, 30, so,
und dann hat dieses Konto am Anfang ein Saldo von null.
Ja, woran liegt das, weil ich natürlich schlampig war?
Mann, ich habe natürlich hier vergessen jetzt zu sagen,
Saldo muss natürlich Anfang Saldo sein.
Anfang Saldo. Kann mir auch mal jemand sagen,
ich glaube, da hat sich jemand gemeldet,
der wollte mir das wahrscheinlich sogar sagen.
Also, wir machen das jetzt nochmal, so,
ja, New Girokonto, juhu, ich kann übrigens hier Auswahl nochmal so.
Und dann, zack, habe ich hier jetzt hoffentlich 30
auf meinem Konto.
So, ja, ich weiß,
es ist große Kunst
Und in dem Moment, in dem man explizit einen Konstruktor definiert,
gibt es auch nicht mehr den parameterlosen Konstruktor.
Also nur wenn man gar nichts über einen Konstruktor sagt,
dann kriegt man einen parameterlosen Geschenk. Wenn man aber einen hinschreibt,
zum Beispiel mit Parametern hat man nicht noch zusätzlich einen Parameterlosen.
Wenn ich jetzt noch einen parameterlosen gerne hätte,
der dann das Ding mit null initialisiert,
dann würde der entsprechend nochmal extra geschrieben werden müssen jetzt von uns.
Okay, wenn wir mal hier weiterkommen.
Das mit der Objekterzeugung war ja schon genau der Punkt jetzt.
Was mir ganz wichtig ist, dass ihr unterscheidet zwischen einem Konstruktoraufruf, und einem Konstruktor.
Was ihr hier gesehen habt, gerade im Quelltext,
was ich da geschrieben habe, das ist ein Konstruktor.
Versteht bitte einen Konstruktor, idealerweise als einen Initialisierer,
der initialisiert ein neu erzeugtes Objekt.
Ihr erzeugt aber eigentlich ein neues Objekt durch einen Konstruktoraufruf. Das,
was ihr hier seht, zum Beispiel dieses Schlüsselwort New hier,
New Quadrat, das erzeugt tatsächlich ein neues Objekt.
Also Objekte erzeugen wir mit dem Schlüsselwort New,
in dem wir hinter dem New dann einen Konstruktor einer
Klasse angeben
So, und das ist eben halt,
genau das ist jetzt ein Konstrukteaufruf, mit New bewirkt zweierlei.
Erstens wird ein neues Objekt erzeugt und zweitens wird dann
auf diesem Objekt oder an diesem Objekt der Konstruktor aufgerufen,
damit ihr das dann sozusagen in den richtigen Zustand bringt, als Initialisierer.
Das ist hier auch nochmal ganz deutlich, also hier,
so was ist ein Konstrukteaufruf, ja, das ist ein Ausdruck,
der in Java einfach dastehen kann, an verschiedenen Stellen.
Und der befürchtt erstens, es wird ein Objekt erzeugt,
ein Exemplar der Klasse Quadrat.
Und zweitens wird dann auf diesem Objekt der Konstruktor ausgeführt,
der da gerade benannt wurde in dem Aufruf.
Und das führt dann dazu, dass das Ding in einen Anfangszustand kommt.
Das ist die Idee von Objektorientierung ganz zentral,
dass man einen wohl definierten Anfangszustand hat für ein Objekt,
damit man dann hinterher auch Aussagen darüber treffen kann,
in welchem Zustand das Objekt ist, wenn ich bestimmte Methoden aufgerufen habe.
Also wenn man formal Korrektheit nachweisen will, muss man sowas mit einbeziehen.
Okay, Methoden aufrufen habt ihr auch schon gesehen,
wie man das macht. Also das ist in diesem Beispiel
Code ja auch zu sehen gewesen in dem Zeichner.
Zum Beispiel, dass ich dann aufrufe, Wand vertikal bewegen, 80.
Was es auch gibt, ist, dass man eine Methode
des Aktuellen, der aktuellen Klasse einfach aufruft.
Also zum Beispiel, ich kann hier mal etwas zeigen,
das habe ich, glaube ich, jetzt nicht,
als habe ich das hier irgendwo mal ganz kurz überlegen,
letzte Projekte.
Ja, da haben wir noch was.
Zeichnung, Musterlösung. Hier ist die Klasse Zeichner,
wie ihr sie möglicherweise jetzt in der Übung bauen werdet.
Hier sieht man tatsächlich dann auch eine Methode zeichne,
die bekommt als Parameter eine Farbe, damit man dann die
Farbe der Hauswand irgendwie auch angeben kann von dem Haus,
was man zeichnet.
Und hier ist dann eine weitere Methode,
Zeichner Häuser,
die zeichnet mehrere Häuser
Und die ruft zum Beispiel hier auf,
eine Methode Zeichnerhaus und Zeichnerhaus ist eine Methode innerhalb dieser Klasse.
Das heißt, die kann ich hier, und die ist privat,
eine private Methode, die ist sozusagen nur innerhalb dieser Klasse aufrufbar.
Also wenn man jetzt hier genau guckt, dann sieht man hier,
Zeichnerhäuser ist public und die andere Methode da oben ist auch public.
Das heißt, diese beiden Methoden sind tatsächlich aufrufbar.
Wenn ich jetzt ein Exemplar erzeuge von dem Zeichner hier,
dann hat der tatsächlich nur diese beiden Methoden und diese Methode Zeichnerhaus ist ein Teil der Implementation.
Das ist also privat nur innerhalb der Klasse aufrufbar.
Aber sie ist dann auch wirklich So aufrufbar,
wie auf dieser Folie nämlich einfach,
ohne dass man ein Objekt davor schreiben muss.
In der Objektorientierung ist es halt relativ weit verbreitet,
dass man so Methoden aufruft von anderen Objekten,
in denen man den Methoden das Objekt angibt,
dann einen Punkt und dann einen Methoden namen.
Das ist die Punktnotation in der Objektorientierung. Dot Notation,
sehr zentral. Nicht alle Programmiersprachen halten sich daran, dass es
ein Punkt ist. Aber die Grundidee ist immer die gleiche,
man hat ein Objekt und ruft an dem Objekt irgendwie eine Methode auf.
Also eine Dienstleistung des Objektes. Und eventuell gibt man da
noch dabei Parameter an und konkretisiert für Java sieht es dann so aus,
dass man In dem Fall jetzt hier eine Referenz hat auf ein Objekt,
dann der Punkt, dann die Methode und dann aktuelle Parameter.
Kann einer sein, kann mehrere sein und so weiter.
Das also auch nochmal so als Hintergrund. Dann gucken wir
uns jetzt zum Schluss noch die Methoden-Definition an, nochmal ein bisschen genauer.
Da haben wir das gleiche Spiel wie schon bei den Klassen.
Es gibt den Kopf einer Klasse und den Rumpf einer Klasse
und genauso gibt es dann bei den, in einer,
in dem Rumpf einer Klasse vorzufindenden Methoden, gibt es auch wieder diese Zweiteilung.
Einmal gibt es den Kopf der Methode Der besteht zum einen
aus diesen ganzen Informationen, die ihr hier üblicherweise so kennt.
Also so ein Zugriffsmodifikator wie Public oder Private,
dann so ein Ergebnistyp, gucken wir uns gleich mal an ein Beispiel.
Und dann der Name der Methode und dann irgendwelche möglichen Parameter.
Und idealerweise steht halt bei einer Methode immer auch ein Kommentar dabei,
der einem Klienten erläutert, was denn diese Dienstleistung ausmacht.
Weil der Klient, und das müsst ihr euch immer wieder klar machen,
es weiß ja nicht, was da für Imperative Anweisungen drinstehen.
Oft will ich auch gar nicht da reingucken.
Ich will einfach nur das Ding aufrufen, mach mal hier Dienstleistungen,
ich will dich jetzt haben.
Und nicht erst lesen, was da genau passiert
Also das ist relativ wichtig, dass dieser Kommentar für einen Klienten geschrieben ist. Okay,
dann ist es natürlich auch wieder so,
dass die Signatur einer Methode in Java,
die ist eigentlich hier so rein kodiert, ja, in den Namen,
einmal der Name und einmal die Typen und Reihenfolge und Anzahl der Parameter.
Gut, zum Schluss zwei verschiedene Arten von Methoden.
Einmal gibt es verändernde Methoden. Das ist zum Beispiel so eine,
wie wir sie jetzt gerade hier in unserem Girokonto haben.
Diese Methode einzahlen verändert ja den Zustand des Objektes
Ich zahle einen Betrag ein und dadurch wird der Zustand des Kontos verändert.
Ich kann mir aber auch jetzt zum Beispiel vorstellen,
eine Methode zu schreiben, die lautet, Public Int, Saldo oder Gibsaldo.
Und die soll mir Informationen lieber liefern darüber,
wie viel denn auf dem Konto gerade drauf ist.
Also kann ich hier jetzt einfach schreiben, return, Saldo.
Und dann wird sozusagen die Belegung von dieser Exemplarvariablen ausgelesen und dann an den Aufrufer zurückgegeben. Das ist tatsächlich möglicherweise erstmal jetzt für euch nicht ganz nachvollziehbar,
warum das notwendig ist, weil ich kann ja eigentlich,
wenn ich hier mit dem Objektinspektor draufgehe, auf so ein Exemplar,
ich mache mal hier wieder so ein Girokonto mit 30 irgendwie, so,
das kann ich ja hier mit dem Objektinspektor drauf gucken und sehe ja den Saal,
aber das ist was, was nur in Blue Jay geht,
ja, in der normalen Programmierung könnt ihr nicht einfach in so ein Objekt reingucken, das geht nicht.
Das heißt also, ich möchte wirklich programmatisch fragen können,
was ist denn dein Saldo?
Und dann kommt mir tatsächlich hier diese 30 als Ergebnis raus.
Das kann ich auch tatsächlich im Quelltext hinschreiben,
also ich kann hier schreiben, Girokont,
das ist jetzt hier die Direkteingabe von Blue Jay, ganz hübsch.
Punkt, gib Saldo
Kann ich hier einfach so hinschreiben. Und dann kommt halt einfach 30 raus als Wert.
Und ich kann tatsächlich auch in i, ja,
eine Variable hier jetzt mal eben on the fly mal eben,
das ist eine lokale Variable, mehr oder weniger, deklarieren.
Und dann, ach Mensch, ich mach's mal anders, so.
Schreibt dann hier in i ist gleich, 10 plus Gibsaldo.
Ja, also das ist tatsächlich so,
dass ich ein bisschen breiter machen hier,
dass ihr das auch sehen könnt
Dass ich tatsächlich so einen Aufruf einer Methode,
die ein Ergebnis liefert, mitten in einem Ausdruck haben kann.
Also zum Beispiel hier 10 plus Gibsaldo. Ich glaube,
ich muss hier jetzt einen Semikolon dahinter setzen. So,
und dann kann ich jetzt mir den Wert von I geben lassen.
Einfach mal, was ist denn der Wert von I?
Da sagt er 40. Klar, 10 plus die 30 Liter rauskamen.
Das ist also ganz hübsch in Blue Jay,
aber worauf es mir hin ankommt, ist, es gibt verändernde Methoden.
Die haben halt üblicherweise, nee, die haben den Rückgabewert,
Void. Und dann gibt es die sondierenden Methoden,
die eigentlich den Zustand abfragbar machen. Das heißt,
ich kann als Objekt jetzt ein anderes Objekt nach seinem Zustand fragen.
Und dann wird mir als Ergebnistyp irgendwas geliefert. Und dieser
Ergebnistyp kann sogar wieder direkt in Ausdrücken verwendet werden und damit weitergerechnet werden.
Okay. Ja, und damit sind wir auch für heute
eigentlich durch.
Das ist die Zusammenfassung