Dann also jetzt herzlich willkommen zur elften Vorlesung von SE2.
Heute wird es besonders interessant. Das ist eines der Themen,
die ich persönlich sehr spannend finde. Aber vorher noch ein
anderes spannendes Thema. Wie ihr ja mitbekommen habt,
machen wir einen ziemlichen, treiben wir einen ziemlichen Aufwand,
um unseren Übungsbetrieb so zu fahren,
wie wir ihn momentan fahren.
Wir sind extrem auf studentische Hilfskräfte angewiesen
Im letzten Wintersemester bei SE1 hatten wir 45 Betreuer.
Davon waren sechs Vimies und 39 waren Studierende, also chillmische Hilfskräfte.
Wir könnten das nicht schaffen, diesen Übungsbetrieb,
wenn wir nicht viele studentische Hilfskräfte einsetzen würden. Das heißt,
auch jetzt wieder an euch, der Appell,
wenn euch der Übungsbetrieb Spaß gemacht hat und wenn ihr das Gefühl habt,
dass die Themen, die wir hier vermittelt haben,
einigermaßen sinnvoll waren und ihr das Gefühl habt,
ihr würdet das auch gerne den Nachfolgenden studierenden Generationen zugutekommen lassen
Dann bewerbt euch doch als Hilfskraft für SEIs im nächsten Wintersemester.
Hier so ein paar Randdetails. Wir haben also 14 Labortermine zu
je drei Stunden. Das sind, ihr habt nur 13 miterlebt,
aber es sind sozusagen in der Abrechnung für uns 14.
Dann gibt es eine Betreuerrunde, also die Betreuenden,
treffen sich einmal in der Woche für eine Stunde,
um das Aufgabenblatt der letzten Woche nachzubesprechen.
Also was ist so passiert, was ist schiefgegangen,
was war besonders lustig.
Und auch das Aufgabenblatt der nächsten Woche vorzubereiten
Das ist jeweils eine Stunde. Wir haben witzigerweise die letzten Jahre es nicht mehr geschafft,
alle 45 oder alle 45 oder alle 35,
wie viele es jeweils in den Jahren davor waren,
Betreuenden auf einen Termin zu kriegen.
Wir mussten also dann schon zwei beziehungsweise, glaube ich,
im letzten Durchlauf drei Termine ansetzen. Drei Termine in der Woche,
wo dann ein Teil der Betreuenden sich getroffen hat für diese Vorbesprechung.
Aber auf jeden Fall sollte man, wenn man betreut,
an dieser einen Stunde teilnehmen. Das heißt,
das werden dann aber mehr als diese zu leistenden Stunden bezahlt.
Gut, für diejenigen, die sich auch noch vorbereiten müssen,
ist das natürlich auch noch die Zeit mit einzugerechnen
Aber es bezahlt werden insgesamt 70 Stunden für eine SWS.
Also wenn ihr eine Laborgruppe betreut, dann entspricht das einer SWS.
Und ihr würdet das also mit 615 Euro vergütet bekommen.
Und wenn ihr zwei Gruppen macht, dann entsprechend mit
entsprechend mehr Geld. Das ist besonders dann empfehlenswert,
wenn man effektiver sein will,
weil dann muss man natürlich nicht mehr zweimal vier Stunden die Woche rechnen,
sondern nur nach sieben Stunden die Woche,
weil man ja die eine Besprechung für beide Gruppen
machen kann
Ihr wisst, dass das,
was da so passiert im Übungsbetrieb, ihr habt das mitbekommen,
wir haben auch jetzt in der zweiten Laborphase von SE2 etwas andere Bedingungen,
aber in SE1 ist es durchgängig so,
wie in der ersten Laborphase, also jede Woche ein Aufgabenblatt,
ihr müsst den Leuten die Aufgaben abnehmen,
ihr müsst ihnen aber auch assistieren,
ihr sollt ihnen helfen, die Aufgaben zu lösen.
Das trainiert diverse Softskills,
also neben dem finanziell vielleicht einigermaßen attraktiven Angebot geht es eigentlich primär darum,
für diejenigen unter euch,
die sich im Unibetrieb wohlfühlen und das Ganze gut finden,
dass sie dadurch den Stoff nochmal deutlich vertiefen Also,
wenn ihr Betreuer seid, dann werdet ihr nach einem Semesterbetreuung deutlich mehr wissen,
als ihr jetzt nach einem Semester konsumieren des Inhaltes habt.
Aber es geht eben halt auch darum,
dass ihr so ein bisschen lernt, mit anderen Menschen umzugehen.
Das ist ja was, was bei der Softwareentwicklung durchaus wichtig ist,
dass wir immer wieder betonen, dass man auf Menschen zugehen kann,
dass man auch Dinge gut darstellen kann.
Ich nutze auch ein bisschen Mut haben. Das ist also nicht so ganz ohne,
da auch vielleicht mal eine eigene Lücke sich einzugestehen gegenüber einem Studierenden.
Das ist insbesondere natürlich gerade ein bisschen schwieriger,
wenn ihr selber noch gerade erst ein Jahr weiter seid,
aber da solltet ihr eben halt keine Angst vorhaben.
Wie gesagt, wir haben sehr gute Erfahrungen gemacht,
damit mit euch als ständischen Hilfskräften.
Und es besteht eben da auch die Möglichkeit,
durchaus in der Betreuerrunde dann auch durchaus konstruktive Kritik zu äußern,
in dem Sinne, dass man möglicherweise SE1 zukünftig anders gestalten könnte.
Also all das ist durchaus möglich. Wenn das für euch
attraktiv ist, dann meldet euch bitte bei SE-Bindestrich Orguide,
Informatik, bla bla.
Das ist momentan eine generische Adresse,
weil Christian Späh,
momentan im Elternurlaub ist
Der ist Eltern, der ist Vater geworden.
Von Zwillingen, sensationell. Und deswegen macht er jetzt erst
mal ein bisschen Pause, kommt aber im September wieder.
Das heißt also, ihr werdet ihn wieder erleben im
kommenden SE1, wenn ihr euch bewerbt für diese Tätigkeit.
Mal einfach so in die Runde gefragt, für wen wäre das eine attraktive Tätigkeit?
Wer hätte da Interesse daran, das zu machen?
AO1, 2, 3, 4, 5,
6, 7, 8, A10, super.
Genau herrlich. Also meldet euch bitte und dann klären wir
die weiteren Details. Was man vielleicht auch noch sagen könnte ist,
um das Ganze noch ein wenig attraktiver zu machen.
Zumindest war es die letzten Semester so,
dass man zusätzlich zur Betreuung im Labor noch weitere Veranstaltungen besucht,
einen Wochenend-Workshop, einen Tag für Softskills zum Einstieg, dann einen Wochenend-Workshop.
In der Mitte des Semesters, um sehr spezifisch nochmal so
SE1-Situationen zu üben und einen Abschlusstermin am Ende der Vorlesungszeit.
In der Summe kann man das dann kumulieren und dann
kann man da tatsächlich dann nochmal drei Leistungspunkte machen.
Man kann das also als ABK-Modul belegen. Ich weiß noch nicht genau,
ob das im nächsten Wintersemester auch wieder möglich sein wird.
Mein letzter Kenntnisstand ist, dass das auch möglich sein wird
Ich weiß es nicht sicher. Also da einfach auch,
wenn ihr euch über diese E-Mail-Adresse hier bewerbt, dann einfach kurz signalisieren.
Ich hätte auch Interesse, zusätzlich noch diese drei Leistungspunkte ABK mitzumachen.
Ihr könnt diese drei Leistungspunkte auch im Wahlbereich anrechnen lassen.
Ihr müsst ja einen bestimmten Anteil im Wahlbereich des Studiums erbringen.
Ich glaube, das sind so 18,
je nachdem welcher Studiengang 18 oder 24 Leistungspunkte.
Und da könnt ihr immerhin schon drei da sozusagen einfahren,
indem ihr das macht.
Also auch das bitte dann in der Mail
entsprechend bekunden
Gut. Gibt es da noch Fragen dazu zu dieser Möglichkeit?
Bitte? Allgemeine berufsqualifizierende Kompetenzen. Es gibt ein Methodenkompetenzmodul,
das ihr, glaube ich, in euren Studienplänen habt.
Das gehört zu diesem ABK-Anteil. Es gibt auch Anteile von Pflichtmodulen,
die, also Teile von den Pflichtmodulen, die dann in den ABK-Anteil reingerechnet werden.
Es gab mal eine Auflage, als Bologna eingeführt wurde,
dass ein Anteil, ich weiß nicht,
wie viel das genau ist, aber so 27 Leistungspunkte,
also fast schon 10 Prozent von den 300 Leistungspunkten dann als ABK anrechenbar sein muss.
Also irgendwie ausgegewiesen sein muss im Sinne von ABK. Also Dinge,
die über das stoffliche Inhaltliche hinausgehen, eben halt allgemeine Berufsqualifizierende Kompetenzen.
Das war so ein bisschen die Forderung, dass die Uni-Ausbildung
ein bisschen praxisorientierter werden sollte. Da haben sich die Unis
teilweise gegen gewehrt, aber das ist ein anderes Thema. Gut,
ja, heute erzähle ich etwas über Fachwerte,
über Werttypen und wir in den letzten Jahren bei der Beschäftigung mit diesem Thema,
also wir beforschen das Thema auch selber ein bisschen, festgestellt haben,
dass das eigentlich eine wunderbare Brücke ist aus der objektorientierten Programmierung in die funktionale Programmierung.
Und die funktionale Programmierung ist ja etwas,
was ihr hier im Studium durchaus auch genießen dürft,
wenn ihr SE3 belegt, dann könnt ihr euch damit funktionaler Programmierung beschäftigen.
Ist sehr sinnvoll. Und ich will jetzt einfach mal so
aus Neugierde wissen, wie das denn bei euch aussieht.
Also ich, ja, ja, machen wir später.
Wenn ich, ich frage, was so eure Vorkenntnisse sind,
in Bezug auf funktionale Programmierung. So, ich hoffe,
dass das jetzt hier auch wieder klappt, wie viel Vorerfahrung.
Ihr müsst keiner haben, es ist wieder keine Erwartungshaltung da.
Es interessiert mich einfach nur so als eine Erhebung.
Also wer jetzt sein Netzgerät dabei, das kickern schon die ersten Stimmen rein.
Soll ich nochmal den Barcode zeigen? Ja, gut,
dann machen wir das nochmal hier. Der QR-Code,
mit dem ihr euch beteiligen könnt an dieser Erhebung,
einfach mal um den Kenntnisstand
In Bezug, ah, da hat es gepiept,
toll, das hört sich gut an. Okay. Also,
die Frage ist, wie viel Vorerfahrung hast du mit funktionaler Programmierung?
A, gar keine B, ein wenig,
eher im Selbststudium, aber sich mal damit beschäftigt.
Hatte das Thema schon in der Schule,
es gibt Leute unter euch,
die haben Informatik in der Schule gehabt und im Leistungskurs oder im,
was weiß ich,
Vertiefung oder wie das jetzt heißt und da vielleicht dann
auch funktionale Programmierung durchaus mit behandelt
Dann gibt es die Option D,
wenn jemand schon professionell in mindestens einer funktionalen Sprache programmiert.
Oder wenn jemand sogar umfangreiche Erfahrungen hat mit mehreren funktionalen Sprachen.
Also einfach mal jetzt hier so ein bisschen die Stimme abgeben.
Also wenn jemand umfangreiche Erfahrungen mit mehreren funktionalen Sprachen im Selbststudium
hat, dann nimmt er natürlich eh.
Weil da steht ja jetzt nicht, dass es beruflich sein muss.
Es ist ja auch nur so eine ungefähre Erhebung.
Es geht ja hier nicht um irgendwas Formales.
Ich will einfach mal so ein bisschen so sehen,
wie der Kenntnisstand da ist
Gut, 42 Stimmen, ein Traum, das ist nahe 43, okay.
Gut, dann warte ich jetzt noch ein bisschen,
nein, ich warte nicht mehr.
Gucken wir einfach mal, wie so die Verteilung ist.
Okay, das ist so der übliche Wert.
Also hier gibt es jetzt kein richtig und kein falsch.
Es sind zwei Drittel, haben gar keine Vorerfahrung.
Dann gibt es so ein Sechstel,
die hatten das Thema schon in der Schule und es gibt vereinzelte,
die schon deutlich mehr Erfahrung haben.
Dann kann man gucken, wie das hier so sieben Prozent,
wir können das mal in absoluten Stimmen sehen,
also hier drei Leute,
die schon
richtig viel Erfahrung haben
Und einer sogar ganz viel Erfahrung, sehr, sehr schön.
Aber wie gesagt, in der, in der überwiegenden Zahl
ist das natürlich für euch noch ein neues Thema. Und ich kann euch beruhigen,
ich werde jetzt nichts über funktionale Programmierung erzählen, aber diejenigen,
die so ein bisschen was von funktionaler Programmierung verstehen,
die werden möglicherweise schon sehen, worauf es denn hinausläuft,
nämlich wie man das ein bisschen zusammenkriegen kann.
Okay. Aber bevor ich jetzt richtig einsteige in die Folien
, habe ich noch ein kleines Problem.
Jeder von uns hat ja kleinere Probleme oder größere Probleme.
Ich habe ein kleines Problem mit einem kleinen Programm
Das macht nicht das, was es machen soll.
Und wer kann mir sagen, was ich falsch mache?
Ich starte mal Blue Jay. Das hier ist ein kleines System,
eine Anwendung, sehr übersichtlich, gebaut, mehr oder weniger nach den Entwurfsregeln hier für SE2.
Wir haben also hier eine Start-up-Klasse, wir haben hier ein Werkzeug,
einen Medienerfasser, dieser Medienerfasser hat offensichtlich eine Medienerfasser UI,
also die UI-Elemente sind da ausgelagert,
damit das Layout da schön gekapselt ist und hier der Medienerfasser kümmert sich um das,
was man so tun kann, als Mensch,
wenn man mit der Gui interagiert.
Und es geht hier in dem Teil, in dem fachlichen Teil,
seht ihr auch hier, um Compact Discs, CDs,
wie sie auch genannt werden im Volksmund,
die ihr vielleicht gar nicht mehr kennt,
weil ihr nur noch mit MP3s umgeht.
Dann gibt es das Interface mietbar, dann gibt es hier ein Miet bei Info.
Das sind alle Sachen, die habt ihr schon mal gesehen.
Hier ist auch schon so ein erster Fachwert, ein Werttypdatum.
Gut, ich zeige erst mal, was das Ding macht.
Also starte mal hier
diese Main-Methode
Okay, und das ist hier so ein Teil jetzt von dieser Mediathek,
könnte man sich so vorstellen,
wenn es in der Mediathek nicht nur darum geht,
Dinge zu verleihen oder vorzumerken oder ähnliches,
sondern tatsächlich auch Medien zu erfassen.
Das heißt, ich kriege irgendwie neue Sachen rein,
da müssen die im System erfasst werden und dafür könnte jetzt diese kleine Grün sein.
Also es ist ausgesprochen mittelmäßig von mir implementiert, wie man sieht.
Die Oberfläche sieht nicht sehr attraktiv aus, es geht also hier um CD-Erfassung.
So, und ich zeige jetzt einfach mal,
wie man das so benutzen kann. Ich habe jetzt hier,
bin mal wieder sehr kreativ, Paul Weller, Großartiger Musiker,
der hatte ein Album, das hieß Paul Weller.
Ich weiß nicht, Laufzeit irgendwie, boah, 56 Minuten,
keine Ahnung. Und das war sein erstes Solo-Album. Okay,
und das kann ich hier so erfassen, zack,
und schon habe ich hier eine Liste der erfassten CDs.
Paul Weller, hier kann ich tatsächlich jetzt,
und dann kann ich auch noch vielleicht ein weiteres Album erfassen,
irgendwie Wildwood, was weiß ich, 65.
Und jetzt hatte ich hier mir was ganz, ganz Tolles überlegt,
wie ich jetzt hier mir sparen kann, irgendwie lange Kommentare zu schreiben,
wo es sozusagen nur eher um so eine Bewertung geht oder so.
Ich habe mir gedacht, ich möchte jetzt hier einfach drei Sterne eingeben.
Also drei Sterne. Ihr kennt ja so diese Sternebewertung irgendwie.
Ein Stern ist so, eher schlecht.
Da stellen das so mittelprächtig und fünf Sterne ist super.
Ich habe einen Kollegen in der Firma von Heinz Züllichhofen,
der dafür berühmt oder berüchtigt ist, Wagner-Fan zu sein.
Und der hat dann auch so eine Skala von Bewertungen für Dinge.
Er sagt dann, Dinge sind prächtig, das sind so
zwei Sterne. Drei Sterne sind dann prächtig prächtig.
Das ist schon besser.
Herrlich ist dann
vier Sterne
Kann man mögen. Und göttlich ist dann
das höchste der Gefühle, das sind dann fünf Sterne.
Wie gesagt, es ist sehr Wagner geprägt. Davon mal ab,
ich habe jetzt hier gedacht, ich mache das mal mit diesen drei Sternen,
dass da jetzt zum Beispiel prächtig, prächtig erscheint.
Also CD erfassen und was passiert? Hier, der Kommentar,
es bleiben die drei Sterne. Ich weiß nicht genau,
was da schief ist und ich zeige euch mal einfach
diese Anwendung und dann könnt ihr mir vielleicht verraten,
wo ich da was falsch mache.
Ich muss eigentlich nicht viel zeigen,
ich muss nur den Medienerfasser zeigen, ein Werkzeug nach den Entwurfsregeln,
also die Werkzeugklasse des Werkzeugs
Entsprechend Medienerfasser UI, dann wird hier die UI erzeugt,
dann wird hier aufgerufen, registriere Listener, ja,
also hier werden jetzt die Listener an den UI-Elementen registriert,
also einmal hier, wenn der Erfassen-Button geklickt wird,
dann soll ein Medium erfasst werden und wenn Action performt hier ist,
also an einem Löschen-Button,
dann soll das letzte Medium gelöscht werden.
Ich kann also tatsächlich jetzt hier auch in meiner tollen Oberfläche sagen,
hier, Letzte löschen, zack, dann ist dieses Ding,
was sowieso nicht so richtig gut aussah, auch wieder gelöscht.
Sensationell, also was man hier alles so bauen kann,
ja, und hier, der Erfassen-Button wurde geklickt,
sammeln der Textfeld-Inhalte und erstellen einer kompaktesten Falsches möglich.
Da ist hier ein bisschen hässlicher Code, also so Interpretier,
Interprettitel, das wird jetzt alles aus den UI-Elementen ausgelesen.
Laufzeit, Text, Kommentar, dann wird hier die Laufzeit,
wird irgendwie, die ist ja als String eingelesen,
soll aber ein Inteacher draus gemacht werden,
also muss ich das mit einem Inteacher-Pass-Ind machen oder kann ich mit einem Inteacher-Pass-Ind machen.
Ihr wisst, dabei kann eine Acception auftreten,
deswegen mache ich das hier in einem Trike-Catch-Blog.
Da wird hier also irgendwie soweit alles gemacht, dann wird
hier eine neue Kompakt-Dist angelegt, wenn alles gut läuft.
Und dann wird hier das in der Liste hinzugefügt und
dann wird hier irgendwie der Text irgendwie entsprechend neu gesetzt.
So, sehr schön. Und was man hier oben sieht,
ist das, was ich mir überlegt hatte, Kommentar,
da soll jetzt irgendwie der Kommentar durch einen anderen Kommentar ersetzt werden,
nämlich hier Kommentar umwandeln, also da wird ein Kommentar reingetippt,
zum Beispiel drei Sterne.
Und ich möchte jetzt, dass da eben halt was anderes rauskommt.
Das ist die Stelle, wo ich mir jetzt so richtig clever was überlegt habe.
Und hier ist jetzt der Quelltext, Kommentar umwandeln,
man steckt ins Dring rein und kriegt ins Dring raus.
Ja, eigentlich alles super,
wenn ein Kommentar gleich fünf Sterne ist,
dann soll göttlich rauskommen und wenn ein Kommentar gleich drei Sterne ist,
soll prächtig,
prächtig rauskommen
Warum klappt das nicht? Was ist denn jetzt hier falsch?
Ich verstehe das nicht. Hat jemand eine Idee? Ja, da?
Ja, zwei Screens, die wollen wir noch kurz vergleichen.
Verdammt. Stimmt. Okay, ja, also das heißt,
hier werden ja die zwei Strinks mit gleichgleich verglichen.
Okay, also hier stattdessen Equals benutzen, okay,
okay, okay, ich versuche das mal.
Ja, hier, Equals und hier
Okay, das lässt sich übersetzen. Okay, okay,
okay. Und du meinst, das könnte das Problem lösen?
Mal schauen. Wir übersetzen Start-up. Ich tippe hier mal
irgendwas rein. Ach, das geht mir ja,
ach, das geht natürlich nicht.
Muss er ja, sonst stützt mir der Paza ab.
Und hier jetzt mal sehen, drei Sterne, CD erfassen.
Hier steht da prächtig, prächtig. Großartig. Mal gucken,
ob das auch mit fünf Sternen noch funktioniert.
Weitere CD erfassen. Göttlich. Sehr schön. Okay,
also das hat geklappt
Vielen Dank für die Unterstützung. Ich habe das natürlich gewusst.
Also behaupte ich jetzt einfach mal. Was passiert da?
Was ist da jetzt gerade noch mal so passiert?
Wenn ich in der Gui was eintippe,
dann wird von dem Gui-Element dieses Trink umgewandelt,
diese Zeichenketten, die Zeichen, die da eingetippt werden,
werden in ein 1-Trink umgewandelt.
Im Programm habe ich ebenfalls eins dringend erzeugt,
nämlich ein Literal, tatsächlich an der Stelle,
wo ich das da den Vergleich gemacht habe.
Also hier tatsächlich an diesem Medienerfasser hier an der Stelle,
da habe ich hier direkt Da wird,
das ist eins dringend, eines dringend, eines Dreherzeugung,
ja, ein Literal im Quelltext ist nichts weiter als eines Drehnerzeugung.
Selbst wenn die beiden Zeichenketten aus denselben Zeichen bestehen,
sind die beiden Zeichenketten verschiedene Objekte.
Das habt ihr ja hoffentlich inzwischen mitbekommen.
Strinks sind Objekte und man hat Referenzen darauf.
Und wenn ich einen gleichgleich mache, vergleiche ich die Referenzen.
Ich teste also, ob die beiden String-Objekte dasselbe String-Objekt sind.
Das heißt, ein Referenzvergleich liefert das Ergebnis falls.
In diesem Fall, weil das wirklich verschiedenste Objekte sind.
Und natürlich, ja, der Kommilitone hat es mir glücklicherweise gesagt,
aber das ist aus SE1 ja ein alter Hut
Drinks sollten ausschließlich über E-Quills verglichen werden.
Es gibt keinen Grund, dass übergleich gleich zu machen.
Gibt es wirklich keinen Grund? Das ist die Frage.
Also, meine Frage jetzt hier so,
an die ihr euch inzwischen SE2 erfahrenen Teilnehmer dieser Veranstaltung.
Wie nützlich ist die Tatsache, dass ich mehrere Zeichenketten,
die aus den gleichen Buchstaben bestehen,
erzeugen kann und trotzdem unterscheiden kann voneinander?
Also, dass ich wirklich sagen kann, es sind zwei Stringobjekte,
die repräsentieren zwar denselben abstrakte Zeichenkette,
aber diese Stringobjekte sind verschieden.
Wo würde mir
das etwas nutzen
Das ist immer so der Punkt in meiner Veranstaltung,
wo ich dann den höchsten Orden ausschreibe, den ich so habe,
einen Snickers. Also wenn mir da jetzt irgendwas liefert,
wenn mir da jetzt irgendwas liefert, wo er sagt,
ja, es gibt so Situationen, da ist das wirklich richtig nützlich,
dann würde ich diesen Snickers bereit sein, rauszugeben.
Der liegt erst seit ein paar Jahren in meiner Schublade.
Nein, ich würde den frischen Snickers rausgeben, gar keine Frage.
Also auch jetzt hier so spontan jetzt keine Vorschläge,
wo das an irgendeiner Stelle nützlich wäre
Ich vermute, es liegt daran, dass es einfach völlig unnütz ist.
Man braucht das nicht. Die Strings in Java sind ziemlich spezial behandelt.
Mit dieser Unterstützung für Stringliterale und auch dieser Möglichkeit,
sie zu konkatinieren über das Plus. Das ist also das,
was hier so möglich ist. Ich kann Literale definieren,
ich kann Plus tatsächlich benutzen fürs Drinks und kann dann das Drinks miteinander verketten.
Und Strings sind unveränderlich. Das ist speziell,
was trinkst du, aber nicht nur bei Strings.
Ich kann ja auch eigene Klassen bauen, die so unveränderlich sind.
Und es wäre wirklich leicht gewesen,
diesen letzten Schritt noch zu machen in der Sprache,
in der Sprachdefinition zu sagen, wenn zwei Strinks mit gleichgleich verglichen werden,
dann ist das das Gleiche wie S1, Equals S2.
Das hätten die einfach definieren können. Die hätten immer sagen können,
naja, wenn wir das erkennen im Quelltext,
der Compiler, der sieht das ja,
dass das zwei Strinks sind, dann sagt er einfach,
ich mache dann mal einen Equals-Aufruf und kein Gleichgleich.
Haben sie nicht gemacht, ist sozusagen eine kleine Design-Unschönheit.
Wenn das so wäre, dann hätte man tatsächlich,
könnte man wirklich sagen, das Drinks in Java,
sind genauso wie die primitiven Typen in Float
und so weiter.
Und das hat gewisse Vorteile
Ja, diese Typen, diese primitiven Typen haben bestimmte Vorteile.
Und auf die genau will ich jetzt eingehen heute in der Vorlesung.
Stattdessen ist es aber jetzt so, dass Generationen von Studierenden
das ausbaden dürfen und immer wieder in die Falle reinlaufen,
dass sie eben halt dringend mit gleich, gleich vergleichen.
Das macht man aus Versehen immer wieder. Es ist
auch mir schon passiert. Und es ist einfach ärgerlich,
dass man da so eine kleine Fallgrube hat in der Sprache.
Gut. Heute geht es um Fachwerte, Fachwerte sind schon erwähnt worden.
Guido hat schon die Entwurfsregeln hier so ein bisschen eingeführt.
Ich habe nochmal so ein bisschen mir seine Vorlesung angeguckt.
Das Tolle ist ja, dass die hier aufgezeichnet werden.
Konnte also sehen, was er da so nochmal vielleicht vorab
schon gesagt hat
Hat ein bisschen was zu Fachwerten erzählt. Unter anderem,
dass die sich eben halt hier in dieser Hierarchie einordnen,
als die Basiselemente einer Softwarearchitektur. Das sind also die Dinge,
die nur andere Fachwerte benutzen dürfen, aber ansonsten dürfen die keine Materialien,
keine Services und keine Werkzeuge benutzen, die benutzt beziehungsweise sehr hierarchisch hier.
Und er hat auch noch ein bisschen mehr dazu gesagt,
hat auch so ein paar Beispiele schon gebracht,
hat unter anderem gesagt, es ist schön,
wenn man so etwas wie eine Kontonummer oder einen Geldbetrag
nicht mit einem Parameter vom Typ Int modelliert in seiner Anwendung,
sondern tatsächlich sagt, naja, ich definiere einen Typ dafür,
einen Typkontonummer, weil man dann handlungssicherer wird.
Finde ich eine großartige Begründung. Das muss ich mir einfach
auch nochmal so ein bisschen klarer machen.
Das finde ich wirklich gut. Also Handlungssicherheit,
wenn ich das lese im Quelltext, da als Parameter kommt eine Kontonummer,
dann weiß ich einfach, das ist eine Kontonummer.
Wenn da ein Int übergeben wird und im Kommentar steht irgendwo
kein menschliches Kommentar, also Studenten schon gar nicht.
Okay, das ist jetzt gemein,
aber da steht im Kommentar dieser Int,
der da übergeben wird,
soll eine Kontonummer sein
Na toll. Ja, dann kann da eben alles Mögliche kommen,
außer einer Kontonummer. Und weil ja ein Int deutlich mehr
Möglichkeiten hat als das, was dann die Kontonummer vielleicht zulässt.
Und deswegen hat er da schon gesagt, bitte eigene Typen dafür bauen.
Und dieses eigene Typen bauen für solche wertartigen Typen.
Das ist das, was heute das Thema ist.
Er hat damals gesagt, in einer der nächsten Vorlesungen,
nein, es ist tatsächlich heute.
Heute ein Thema in der Vorlesung. Und deswegen geht es
heute um Fachwerte. Also Werte und auch Jeptinnen Programmier machen.
Ich ziehe das Thema ein bisschen, sagen wir, fundamentaler auf.
In dem Sinne, dass ich jetzt quasi grundlegend darüber spreche,
was sind eigentlich Objekte? Und was sind Werte? Und
warum ist es sinnvoll, Werte zu unterscheiden von Objekten?
Und dann so ein bisschen so drauf zu gucken, naja,
woran können wir denn genau erkennen, was Werte sind?
In welchen Situationen wir quasi Werte haben. Es geht also
sehr stark auch um das Modellieren von Anwendungsbereichen.
Das ist ja so das Thema hier in dieser Veranstaltung,
objektotierte Modellierung. Wir wollen Anwendungsbereiche irgendwie modellieren,
mit Begriffen belegen, dass wir sie dann im Softwaresystem
abbilden können
Und da sollte man irgendwie auch schon bei der Modellierung feststellen,
ist das, was wir da so sehen im Anwendungsbereich?
Ist das denn ein Wert oder ist das ein Objekt?
Und im späteren Teil heute werde ich dann drauf gucken,
naja, wenn wir jetzt diese fundamentale Unterscheidung erstmal akzeptieren,
einmal so hinnehmen, dass es da durchaus die Möglichkeit gibt,
die Unterscheidung zu machen, dann könnte man gucken,
wie können uns denn jetzt Programmiersprachen dabei unterstützen?
Wie können die uns da Unterstützung anbieten?
Das ist so ein bisschen so ein Ausblick. Das ist
so auch ein bisschen unsere Forschung. Unsere Vision ist,
dass man irgendwann mal eine Programmiersprache hat,
in der tatsächlich explizit auch Werttypen konstruiert werden können
Und am Ende gebe ich dann die pragmatischen Hinweise, wie wir es,
solange wir uns mit Java rumschlagen müssen, in Java machen.
Ja, und das ist auch das, was so für
die Praktikumsaufgaben dann primär maßgeblich ist. Das Ganze ist,
sagen wir mal, einer der ersten Menschen, die über dieses Thema,
über diese Dualität zwischen Werten und Objekten was geschrieben hat,
war der gute Herr McGlennon in einem vergessenen Artikel in der ACM Sigplan,
Special Interest Group, Programming Languages,
eine altehrwürdige Reihe in der ACM, wo es um Programmiersprachen geht.
Das ist so eine der Grundlagen für diesen Teil.
Außerdem der Bloch immer zu empfehlen, also wenn ich den Bloch
nicht schon empfohlen habe, dann empfehle ich ihn jetzt nochmal.
Zweite Auflage, sehr, sehr gutes Buch, wird später nochmal aufgegriffen.
Der sagt auch ein bisschen was dazu über Unveränderlichkeit und Ähnliches.
Gut, wir sind hier in der Veranstaltung OOPM,
also nicht nur Programmieren, sondern jetzt inzwischen auch modellieren.
Und ich habe, ich unterscheide das gerne, ein bisschen sauber,
dass ich sage, in SE1 machen wir nur Programmieren.
Ihr müsst nicht, ihr musstet nicht in SE1 viel modellieren,
sondern wir haben einfach gesagt, hier ist ein Modell,
Idee von einem Konto, Spezifikation und ihr musstet das nur noch bauen.
Das war Programmieren in SE1. Jeder erfahrene Programmierer modelliert ständig.
Also wenn man programmiert, ist man eigentlich ständig dabei, Modelle zu bauen.
Das ist ganz normal. Das geht also fließend ineinander über.
Nur wir haben es jetzt hier in der Ausbildung ein bisschen schärfer getrennt.
Jetzt kommen wir so in SE2 ja sehr viel stärker mit
dem Thema Modellierung in Kontakt. Und es geht eigentlich jetzt immer darum,
dass wir einen Ausschnitt aus der realen oder einer imaginären Welt modellieren wollen.
Wir modellieren ja nicht nur reale Welten,
sondern auch sowas wie ein Compiler. Ich weiß nicht,
ob ein Compiler schon zur realen Welt gezählt werden kann,
aber der ist durchaus auch komplex und muss auch irgendwie intern aufgebaut sein.
Es ist also auch eine eigene Welt für sich.
Heinz hat einiges erzählt. Guido hat sicherlich schon einiges erzählt zu dieser Idee,
dass wir ja hier eine gewisse Ausrichtung haben,
dass wir sagen, naja, geprägt durch den Werkzeugmaterialansatz sagen wir,
bei interaktiven Systemen arbeiten Menschen üblicherweise mit Werkzeugen an Materialien.
Also hier so ein Werkzeug, das, glaube ich,
mal für das Bundesamt für Zivildienst gebaut worden ist,
von der Firma von Heinz und Vido, wo es darum geht,
irgendwie Zivildienstleistende zu erfassen durch ihren Lebenslauf bei der Bundeswehr oder beziehungsweise als Zivildienstleistende falsch Zivildienstleistende zu begleiten.
Und dann sieht man da eben halt so Dinge wie, ja,
ein Quartal, in dem der vielleicht da erfasst worden ist,
Antragsdatum, dann irgendwelche Zeiträume und dann ZDP,
das ist die Zivildienstleistenden, Personalnummer, keine Ahnung, irgendwie sowas.
Und dass diese Dinge da ja irgendwie tatsächlich auftauchen. Also man hat relativ schnell,
wenn man mit bestimmten fachlichen Dingen umgeht, sowas wie fachliche Werte.
Und die These jetzt und eigentlich nicht nur aus Sicht des Werkzeugmaterialansatzes,
aber da ist es eben halt stark vertreten,
ist, dass in jedem Wenn ihr irgendetwas modelliert,
dann werdet ihr fachlich motivierte Werte erkennen.
Also nicht nur Objekte, sondern auch Werte.
Um das mal so ein bisschen zu illustrieren,
hier so einige Phänomene, die man schwerlich als Objekte modellieren kann.
Also zum Beispiel ein Zeitpunkt. Wenn ich einen Zeitpunkt als ein Objekt modelliere,
ist das irgendwie komisch, weil Objekte werden erzeugt.
Zeitpunkte werden nicht erzeugt. Zeitpunkte sind einfach da.
Man kann sich sozusagen eine Zeitstrahl vorstellen und jeder Punkt auf
diesem Zeitstrahl, der ist einfach da.
Ich kann mir den rauspicken, aber ich muss ihn nicht
erzeugen.
Das ist komisch
Oder einen Zeitraum. Wenn wir den Zeitraum für die Klausur ändern,
nehmen wir mal an, für SE2,
dann ist dieses umgangssprachliche, wir ändern mal den Zeitraum,
dann ändern wir nicht den Zeitraum von 9 bis 11,
den gibt es einfach,
sondern wir weisen der Klausur oder unserem Vorgehen hier einen neuen Zeitraum zu.
Aber der Zeitraum ist schon da, der ist sozusagen.
Diese ganzen Zeiträume gibt es auch schon, sind alle schon da.
Gut, 100 Euro sind doppelter Hinsicht, ein Wert,
haha. Wenn sich bei einem Bankkunden die Kontonummer ändert,
auch da wieder, dann ändert sich nicht die Nummer,
sondern wir weisen dem Kunden eine neue Nummer zu.
Die Nummer selbst wird nicht geändert. Also auch da
Objekte sind eigentlich was Veränderliches, Werte eher nicht.
Und wenn ein Mitbürger eine Sozialversicherungsnummer bekommt, dann wird die nicht frisch erzeugt,
sondern es gibt eine Menge von Sozialversicherungsnummern, die sind gültig.
Sind taktisch gültig, die sind sozusagen. Und dann kriegt
ein Mensch die zugewiesen und dann hat er sie für sein Leben.
So, wenn wir jetzt ein bisschen darauf gucken,
wo Werte eigentlich herkommen, dann kommt man relativ schnell auf die Mathematik.
In der Mathematik sind Werte, was sehr selbstverständlich ist
Da kennen wir sie aber auch total gut her.
Deswegen ist auch die wertorientierte Programmierung, die funktionale Programmierung,
sehr stark in der Mathematik verwurzelt. Wenn man einfach sagt,
alle Methoden sind Funktionen, wir haben nur noch Funktionen und Funktionsapplikationen,
ist ja etwas, was ihr in der Mathematik sehr,
sehr ausführlich kennenlernt oder kennengelernt habt.
Und in der Mathematik gibt es eben halt dann sowas wie ganze Zahlen,
die sind dann abgebildet in der Programmierung auf das Zweierkompliment,
in Java oder rationale Zahlen finden wir dann so ungefähr wieder in den Gleitkommazahlen mit Float und Double,
bulsche Wahrheitswerte,
auch relativ einfach,
kann man
sehr mathematisch modellieren
Findet sich wieder in der Programmierung im Typ Bulli.
Und wenn man jetzt mal drauf guckt, sind das Objekte,
da haben die Java-Leute gesagt, nö, das sind keine Objekte.
Da machen wir jetzt eigene Typen dafür. Viele finden das
hässlich. Viele finden, das ist doof, dass es
in Java diese acht primitiven Typen gibt und die anderen Objekttypen.
Aber es ist zumindest schon mal gut zu sagen,
naja, diese Typen sind eigentlich keine Objekte.
Also wann haben wir jene Vier erzeugt? Ist irgendwie albern zu sagen,
wir erzeugen die Vier, die Vier ist immer schon da gewesen.
Und die Vier können wir auch nicht verändern.
Wir können nicht der Vier eine Nachricht schicken,
sei jetzt mal
die Fünf
Blödsinn. Oder die Zahl P, kann man auch sagen,
hat dir jemand erzeugt oder hat dir jemand entdeckt?
Ich glaube eher, die ist irgendwie entdeckt worden.
Die war einfach da. Oder True und Falls.
Was war zuerst da? So philosophische Fragen kann man sich
ja stellen. Völlig sinnlos. Gut. Das heißt,
irgendwie sind diese diese primitiven Typen,
die wir in Java so kennen und aus der Mathematik motiviert sind,
das sind eher Werte.
Da werden also eher Werte mit modelliert. Dann hat der
gute Nauer auch mal so ein bisschen darüber resultiert,
wann wir denn überhaupt Zahlen verwenden
Gerade in der Programmierung, also sicherlich als zur Identifikation.
Also wenn wir modellierte Gegenstände, Kontonummer, Personalnummer mit einer
Nummer belegen, dann wird das oft mit Zahlen gemacht.
Zum Abzählen und Ordnen von Gegenständen. Klar, das ist
relativ klar und einfach. Oder zur Repräsentation von messbaren Größen
. Wenn wir Metriken anlegen und ähnliches.
Und wenn man numerische Analyse macht in der Naturwissenschaft,
dann ist das durchaus auch stark mit Zahlen durchsetzt.
Das heißt, es ist relativ simpel zu sagen,
alle Zahlen sind Werte
Aber die Frage ist, sind auch alle fachlichen Werte,
die so vorkommen, tatsächlich auch zahlen?
Und die Antwort ist, nein, es gibt eben fachliche Werte,
die bestimmte Eigenschaften haben, die sie durchaus unterscheiden von Zahlen.
Also zum Beispiel hier Postleitzahl oder Bankleitzahl, die haben eine fachliche Bedeutung,
aber ich möchte nicht mit diesen Dingen beliebig rechnen können,
weil es auf mich einfach nicht sinnvoll ist.
Wieder diese These, wenn ich einen Parameter übergeben bekomme,
der eine Postleitzahl darstellen soll,
dann möchte ich das nicht als Int bekommen,
sondern dann möchte ich den wirklich als Typ Postleitzahl bekommen
Weil dann kann ich da tatsächlich nur Dinge damit tun, die sinnvoll sind.
Bei Postleitzahlen ist es nicht so sinnvoll, die zu addieren,
aber bei Kontonummern kann man zum Beispiel sich überlegen,
dass man die auch addieren können möchte,
um zum Beispiel eine Prüfsumme zu bilden über irgendwie Konten.
Zur Sicherheit in einer Bank, aber man wird sie nicht subtrahieren.
Oder auch Geldbeträge, ich weiß nicht,
ob ihr das mal euch mal überlegt habt oder euch klargemacht habt,
dass man Geldbeträge üblicherweise nicht miteinander multipliziert.
Ich kann sagen, das sind dreimal 100 Euro,
also 100 Euro ist ein Betrag und drei ist dann ein Multiplikator,
aber ich sage nicht 100 Euro, mal 100 Euro.
Das ist irgendwie komisch
Man hat da immer nur einen, der dann ein Betrag ist.
Also, dass wir dann irgendwie Betrag zum Quadrat oder so
, komisch. Das mit den Zahlen hier,
mit den Farben, das ist eigentlich schon mehrfach diskutiert worden,
da haben schon mehrere Leute in der Vorlesung gesagt,
naja, eigentlich ist es doch durchaus so,
dass man die RGB-Codes benutzt, um dann Farben zu modellieren.
Also, das kann man auch einfach mal rausnehmen.
Was auf jeden Fall wichtig ist, die Werte,
die wir hier so jetzt, die ich jetzt hier postuliere,
wo ich auch gleich ein Grips mir genauer darauf eingehe,
was denn so Werte sind,
die haben Eigenschaften, die sie klar von Objekten unterscheiden.
Also,
Werte und Objekte sind verschieden
Wie verschieden sie sind. Das werde ich jetzt hier mal
so ein bisschen auseinanderfalten. Wenn man so ein bisschen das
durchgehen, das ist tatsächlich ein Rausarbeiten von diesen Eigenschaften.
Also was sind die zentralen Eigenschaften und wo unterscheiden
die sich? Und dann haben wir vielleicht ein bisschen,
habt ihr ein klares Bild davon für den,
was wir euch hier eigentlich vermitteln wollen, warum wir diese Unterscheidung überhaupt vornehmen?
Also das erste ist mal, ein Wert ist etwas Abstraktes.
Also ein Wert ist immer abstrakt. Abstrakt ist ein abstrakter Begriff.
Ich weiß, es geht aber hier in dieser Veranstaltung nicht auf viel um Attraktion.
Werte sind immer immateriell. Das heißt, sie sind Abstraktionen über Dinge. Also sowas,
zwei Maiskäufen, zwei Äpfel, zwei Eisenstangen, keine Ahnung,
da kann ich immer sagen, das sind immer zwei,
da habe ich eine Abstraktion, immer zwei, zwei,
ja, ist also tatsächlich konkrete Kontexte, ich abstrahiere davon.
Objekte sind häufig konkret, müssen nicht alle Objekte,
die wir so kennen, müssen auch konkret sein.
Es gibt ja auch Objekte, die man so virtuell erzeugt
und ähnliches, aber Werte sind auf jeden Fall abstrakt.
Was ganz elementar ist, was ich auch schon gesagt habe,
was auch schon jetzt ihr mehrfach gemacht habt,
Objekte werden erzeugt und Objekte werden zerstört.
Das heißt,
Objekte haben eine Lebensdauer
Das heißt, ich habe, wenn ich so ein Objekt
mir angucke, dann gibt es irgendwie so drei Zeitabschnitte.
Es gibt vor der Erzeugung des Objektes während der Lebenszeit des Objektes und danach.
Kann also hier Objekt B wird zu irgendeinem Zeitpunkt geboren,
zu irgendeinem Zeitpunkt stirbt das Objekt. Ganz, ganz illustrativ
hier. Hat also hier eine Lebensdauer auf einer Zeitachse.
Und jetzt gibt es eben halt die Zeit davor.
Also das ist hier vor der Erzeugung und nach der Erzeugung.
Und es kann ein anderes Objekt schon vorher erzeugt worden sein,
dass dann irgendwann während das Objekt B noch existiert,
schon das Zeitliche segnet.
Und es kann aber auch hier dieses Objekt B
ein anderes Objekt erzeugen, das vielleicht sogar länger lebt,
als das erzeugende Objekt
Das sind alles so Zusammenhänge, die gibt es einfach bei Objekten.
Bei Objekten denken wir über sowas nach. Da spielt das
eine Rolle. Zeitpunkte, wann sie erzeugt und wann sie
zerstört werden. Das ist überhaupt nicht so bei Werten.
Werte sind zeitlos. Also wenn ich euch fragen würde,
wann ist denn die 42 erzeugt worden, dann ist das eine völlig blöde Frage.
Niemand würde das je fragen, weil es ist nicht wirklich wichtig,
wann die in die Welt gekommen ist.
Sie ist einfach da. Die sind tatsächlich zeitlos. Und
auch wenn man einen Ausdruck auswertet,
dann werden da nicht irgendwie Werte erzeugt,
sondern einen Ausdruck wie 40 plus 2 führt zu einem Ergebnis,
dann so sagt, ah, es ist die 42.
Also die 42 ist aber auch schon immer da gewesen.
Objekte sind potenziell veränderbar. Das heißt,
das ist etwas, was ihr effektiv hier,
das ganze Semester durch und auch das letzte Semester durch gemacht habt.
Ihr habt Objekte modelliert in der Programmierung und die waren veränderbar.
Das heißt, die erkennbaren Merkmale können sich ändern und trotz
der Veränderung dieser Merkmale bleibt die Identität des Objektes meist erhalten.
So ein Auto vor 20 Jahren und jetzt irgendwie vor zehn Jahren,
dann sieht es irgendwie anders aus,
aber es ist irgendwie noch das gleiche Auto,
es sei denn, es sind jetzt alle Teile ausgetauscht worden,
da kann man wieder philosophisch werden,
wann ist ein Objekt Auto noch dasselbe Auto.
Wollen wir hier nicht vertiefen? Während ein Wert unveränderlich ist.
Also Werte sind etwas Unveränderliches. Ihr werdet nicht darüber nachdenken,
wie ihr einen Wert verändern könnt. Also eine 40 zu verändern im Sinne von,
ich schicke dir die Nachricht, idea mal zwei drauf,
auf dich selbst, damit du die 42 bist,
das ist zu objektorientiert.
Das wird eigentlich, das ist nicht sinnvoll, das so zu machen.
Das heißt, Werte können berechnet auf andere Werte bezogen werden,
aber es kommen immer wieder Werte raus, die schon da waren.
Die Objekte, wir selbst werden nicht verändert.
Das ist ganz wichtig, dass Werte unveränderlich sind.
Und das wollen wir
auch nachmodellieren
Also Objekte sind auch zustandsbehaftet. Das heißt also,
ein Objekt hat einen inneren Zustand, hier so ein Einkaufswagen,
man kann irgendwie verschiedene Füllstände haben.
Das ist für euch einfach nachvollziehbar. Habt ihr oft genug gesehen
und Veränderungen finden in der Zeit statt. Das heißt,
ein Objekt hat zu verschiedenen Zeitpunkten einen anderen Zustand. Nebenbemerkungen,
es gibt auch unveränderliche Objekte, aber die sind so ein Spezialfall,
die muss man sich ein bisschen genauer betrachten.
Die gibt es durchaus Beispiele. Die erhalten ihren Zustand üblicherweise
einmalig bei der Erzeugung. Aber die haben wirklich so einen
Erzeugungszeitpunkt. Werte sind zustandslos, im Gegensatz dazu,
also unveränderlich und auch zustandslos.
Das heißt, die verändern sich einfach nicht
Ganz einfach. Werte sind zustandslos. Objekte werden häufig zur Kommunikation benutzt. Also das ist durchaus nützlich,
sowas wie Seiteneffekte zu haben, weil wenn ich,
wenn zwei Rechner miteinander kommunizieren wollen über einen gemeinsamen Datenbereich,
dann ist es gut, wenn beide da irgendwo was reinschreiben können und rauslesen können,
um einfach zu kommunizieren.
Das heißt, das kann gewünscht sein, dass solche Seiteneffekte auftreten,
aber es kann aber auch natürlich zu Problemen führen,
aber wenn man das gut beherrscht, ist das ein sehr nützliches Konzept,
weil dadurch tatsächlich man gut kommunizieren kann zwischen verschiedenen Objekten.
Bei Objekten gibt es ein ganz entscheidendes Element,
nämlich die Unterscheidung zwischen Gleichheit und Identität
Das ist das, was in der deutschen Sprache zum Glück
gut unterscheidbar ist. Zwei Dinge sind gleich. Also ist es
dasselbe Objekt oder ist es das gleiche Objekt? Wenn wir
so zwei Bücher da liegen haben, die sehen völlig gleich aus.
Da sind wirklich die gleichen Bücher gleicher Inhalt, alles gleich.
Dann ist es einfach zu sagen, diese beiden Objekte sind gleich,
aber keiner würde sagen, das ist dasselbe, ob dasselbe Buch.
Es ist sozusagen abstrakt, dasselbe Buch, was da niedergeschrieben vorliegt.
Aber die Exemplare sind einfach da. Man kann sich greifen und
man kann einfach darüber reden, dass das eine, das andere ist.
Und die sind auch tatsächlich ganz wichtig bei diesem Betrachten von Identität
ist auch diese Position in Raum und Zeit.
Wenn ich zwei Bücher habe und das eine liegt hier,
das andere liegt da und dann tausche ich die einfach aus,
in den exakt gleichen Stellen, dann ist einfach klar,
das eine Buch lag eben noch da, jetzt liegt es da.
Ich kann vielleicht nicht mehr herausfinden, ich kann es vielleicht nicht sehen,
das ist jetzt ein anderes Buch,
aber zu einem bestimmten Zeitpunkt lag das eine hier und dann lag es da.
Das heißt, es ist auch in Raum und Zeit
wichtig, wo ein Objekt ist.
Es können nie zwei Objekte zur gleichen Zeit am selben Ort sein.
Das ist einfach Quatsch. Ich kann nicht zwei Bücher,
die würden irgendwie sich überlagern.
Geht nicht. Das ist bei Objekten ganz wichtig.
Bei Objekten ist das elementar
Bei Objekten ist auch eine wichtige Einschaltung, dass sie potenziell kopierbar sind.
Also so ein Begriff von Original und Kopie.
Zwei Objekten total selbstverständlich. Ich habe einen Vertrag da liegen
, dann habe ich eine Kopie von dem Vertrag.
Kein Problem. Bei Werten macht das keinen Sinn. Bei Werten
ist es irgendwie komisch zu sagen, hier ist die 4,
ich mache mir meine Kopie von der 4. Komisch.
Oder Anzahl, Anzahl bei Werten. Wie viele Firmen gibt es
denn so? Ich glaube, es gibt nur eine.
So, es ist einfach irgendwie komisch.
Man kann verschiedene Repräsentationen haben von einer
Das ist was anderes als die vier selbst.
Also das ist irgendwie komisch. So, das heißt,
das, was ich bis jetzt gesagt habe,
war hoffentlich einigermaßen nachvollziehbar, teilweise ein bisschen philosophisch vielleicht,
aber es ist eigentlich gut nachvollziehbar.
Ein Wert ist auf jeden Fall immer abstrakt, zeitlos, unveränderlich.
Das sind schon mal sehr zentrale Eigenschaften von einem Wert.
Und das in Kontrast zu einem Objekt, das ist Zustandsbehaftet,
es muss nicht Zustandsbehaftet, aber es ist meistens zustandsbehaftet und
es ist potenziell veränderbar und es ist erzeugbar und zerstörbar.
Das heißt, es existiert in Raum und Zeit.
Das sind schon mal
ganz wichtige Unterschiede
So, jetzt habe ich das so ein bisschen motiviert,
was so Werte und Objekte sind.
Grundkonzepte in der Softwareentwicklung haben wir jetzt gesehen im Sinne von,
ihr habt ja primitive Werte schon relativ viel benutzt und Objekte haben wir
euch ja auch in der OO-Softwareentwicklung zumindest sehr nahe gebracht.
Wenn ich diese Unterschiede klar habe, dann hilft mir das
stark beim Entwurf und auch bei der Konstruktion von Software.
Das ist einfach so. Also ich sollte eigentlich,
wenn ich auf die Welt schaue und versuche etwas zu modellieren,
da schon so unterscheiden, ist das jetzt ein Objekt oder ist das ein Wert? Das heißt,
diese Unterschiede sollten uns gut bekannt sein und wenn wir Einfach jetzt mal,
also wenn ihr mir jetzt traut und mir glaubt,
dass, wenn ich sage, dass das wichtig ist,
das zu unterscheiden, dann wäre der nächste Schritt jetzt zu gucken,
wie gut sind denn Programmiersprachen darin,
uns bei der Unterscheidung zu unterstützen?
Also, wie gut sind Objektorientierte Programmiersprachen darin,
uns dabei zu unterstützen, Werte von Objekten zu unterscheiden?
Das ist so die offene Frage,
die ich jetzt mal so in die Pause gebe.
Wir machen jetzt mal eben fünf Minuten Pause bis zehn nach
Schauen wir doch mal. Also, ja,
wir glauben an Werte, wir glauben an Objekte.
Wir kennen Objekte, wir wollen jetzt Werte mal besser kennenlernen.
Und jetzt ist die Frage,
wie gut sind die objektorientierten Sprachen da bei uns zu unterstützen?
Wenn wir auf objektorientierte Programmiersprachen gucken, dann ist es die Antwort relativ leicht.
Da werden natürlich in erster Linie Objekte mit unterstützt.
Das heißt, mit dem Schlüsselwort Klaas kann ich ja
neue Objekttypen definieren. Wir nennen das auch einen Typkonstruktor,
das heißt, mit dem Schlüsselwort Klaas konstruiere ich einen neuen
Typ in Java
Bei den Werttypen, die wir ja nachweislich kennen, also hier Java,
Intbite, Short und so weiter, die sind tatsächlich festgelegt.
Da gibt es einfach genau acht Stück. Und das sind die Werttypen,
die zur Sprache dazugehören. Wenn wir jetzt einfach hier postulieren,
dass es viele Anwendungszusammenhänge gibt, wo fachlich motivierte Werttypen nützlich sind,
warum gibt es dann keine Unterstützung für Werttypen?
Warum ist da kein Typkonstruktor für da? Wahrscheinlich,
und das ist so meine These, aufgrund des Strebens nach Purismus.
Also da muss man so ein bisschen in die Historie von Programmiersprachen reingucken.
Und da ist so eine starke Tendenz immer gewesen,
pur zu sein. Also es ist total schick,
wenn man sagt, diese Programmiersprache ist pur objektorientiert.
Also eine Sprache, die das immer gesagt hat, war Smalltalk.
Also nicht Smalltalk hat das gesagt, sondern Menschen haben das über Smalltalk gesagt.
Und in Smalltalk trifft das auch ziemlich weit zu.
Da ist tatsächlich alles ein Objekt. Selbst so int und
so ist ein Objekt. Klar kann man nicht verändern,
aber irgendwie ist es dann doch ein Objekt. Klassen,
auch Werte, auch Blöcke,
also einen Block in einer Programmiersprache sozusagen in einen der Rumpf einer Methode,
ist dann auch ein Objekt, den man eine Nachricht schickt,
führ dich mal aus.
Also sehr, sehr objektorientiert bis ins letzte Detail.
Total toll. Anderes Beispiel ist Eifel, nicht mehr ganz
so aktuell, aber war mal eine Zeit lang sehr aktuell.
Da ist es zumindest zur Laufzeit so, da gibt es
nur noch Objekte, keine Klassenobjekte wie in Java zum Beispiel.
Eine Sprache, die das ins Extrem getrieben hat,
ist Self, keine Klassen. Da gibt es noch nicht
mal mehr Klassen, sondern nur noch Objekte.
Wenn ich ein neues Objekt haben will,
dann muss ich ein anderes bestehendes Objekt klonen.
Das sind dann
exemplarbasierte Sprachen
Da kann man immer fragen, wie sinnvoll ist das denn, so puristisch zu sein?
Also diese Forderung nach, alles ist ein Objekt,
macht alles viel besser und einfacher. Es ist ganz schön,
sich da mal so das Spektrum der Programmiersprachen anzugucken über die Zeit.
Ich habe hier mal so ein aufgemacht hier so rechts,
also für euch rechts, rot,
da sind so die glühenden Objekte mit Zuständen und links sind dann eher so die grauen,
kühlen Werte, die also sich wenig verändern müssen.
Und wenn man jetzt so eine Zeitachse nimmt und einfach mal so guckt,
wie so über die Jahrzehnte sich die Programmiersprachen so entwickelt haben,
dann ist das irgendwie ganz lustig, wie man so sieht,
dass da so ein so ein Spektrum abgedeckt wurde und diese Ränder einfach erforscht wurden.
Also wenn man einmal so sieht, bei den objektorientierten Sprachen hier,
Simula, was ist denn der Urvater der objektorientierten Sprachen,
dann Smalltalk, auch ein Urvater,
dann gab es irgendwie Eifel und dann gab es Self,
also 1987 kam Self raus und das ist sozusagen die eine der extremsten Programmiersprachen,
wo wirklich man nur noch Objekte hat, nichts anderes mehr.
Da ist also der Rand ausgeforscht worden. Interessant ist,
dass mehr oder weniger zur gleichen Zeit,
auf der anderen Seite bei den funktionalen Sprachen,
bei den wertorientierten Sprachen, das ging so,
Lizb ist so der Urvater der funktionalen Sprachen, dann Skim,
ML, Miranda Haskill,
Haskill gilt so als die purste, funktionale Programmiersprache.
Da gibt es nichts anderes außer Werten. Da gibt es keine Objekte,
keine Zustände, keine Variablen, also keine veränderlichen Varianten.
Das ist sozusagen pur wertbasiert. Und diese beiden Rände des Spektrums sind
da ausgeforscht worden. Das sind beides Forschungssprachen. Das heißt,
es gibt in diesen Sprachen vermutlich keine größeren Systeme,
die damit gebaut wurden.
Die sind möglicherweise nicht so praktisch, diese Sprachen.
Praktisch sind die Sprachen in der Mitte,
die versucht haben,
irgendwo so
einen Mittelweg zu gehen
Irgendwie beides zu können. CPlus zum Beispiel sagt von sich,
also Bjarnes Draustrupp sagt über CPlus,
das ist keine objektnorientierte Programmiersprache, sondern das ist eine Multiparadigmen-Sprache.
Multiparadigm Language, da kann man auch objektorientiert programmieren.
Man kann aber auch Funktional programmieren. Oder Skala als letztes Beispiel
jetzt relativ aktuell. Ist auch eine Programmiersprache, die beides kann.
Da kann man objektorientiert programmieren und man kann Funktional prämieren.
Großartig. Das heißt also, die Frage ist,
wenn man jetzt aus softwaretechnischer Sicht drauf guckt,
dann will man nicht diese extremen Ränder haben.
Purismus ist zwar ganz schön, aber muss man auch auch vorsichtig sein,
sondern man versucht irgendwo so einen Kompromiss zu finden.
Und wie gut der Kompromiss ist, das schlicht und im Auge des Betrachters,
welche der Sprachen jetzt hier besonders gut geeignet ist.
Also es gab auch viele funktionale Sprachen,
die dann versucht haben, Objekte und Türen mit aufzunehmen.
Hier, CeLos, Common Lisb Object System, O Camel.
CeSharpe ist auch so ein Ding, was ein bisschen vielleicht
eher funktional ist als Java, weil da mehr Elemente drinstecken.
Wie auch immer. Was spricht dafür, dass man nur
Objekte hat? Das hat gewisse Vorteile. Das Sprachmodell wird möglicherweise
sehr einfach. Man hat ein konsistente Semantik bei Variablen,
man hat nicht also diese Unterscheidung wie in Java mit oh hässlich Element-Typ von einem Array,
kann alles sein oder bei einer Sammlung können es nur Referenztypen sein.
Die Generalizität ist auch so ein bisschen komisch,
wenn man ständig diese Unterschiede macht zwischen Werten und Objekten.
Also gerade so eine Art hoc Regel wie in Java.
Wir haben acht Werttypen und sonst gibt es keine, ist irgendwie komisch.
Das heißt also, das einheitliche Sprachmodell ist natürlich schön,
vielleicht auch für Programmierer ganz schön, aber nicht für Modellierern.
Und wir als Softwareentwickler, Softwaretechniker und Software-Tänikerinnen,
wir sollten ja eigentlich ein Modellierer sein.
Das heißt, wir wollen eigentlich Probleme lösen.
Das heißt, wir müssen Probleme aus der realen Welt
abbilden in den Computer
Und wenn wir dabei gezwungen werden, alles,
was wir da so sehen, was da so kreucht und fleucht,
in der Flora und Fauna, abzubilden auf Objekte,
dann fangen wir an, hier so, ja,
Puddelsquare and around hole oder Square Pack into around hole.
Das ist, glaube ich, im Englischen der Besprochen.
Also dann versuchen wir hier so eckige Klötze
irgendwie so in runde Löcher zu stopfen.
Das ist irgendwie komisch. Also wenn wir gezwungen werden,
alles, was so wichtig ist in einem Anwendungsbereich,
mit Objekten zu modellieren, dann verbiegen wir uns bei den Werten.
Und dieses Verbiegen bei den Werten, das werden wir auch gleich sehen.
Wenn wir nämlich versuchen, wertartige Dinge in Java zu bauen,
dann gibt es immer irgendwie einen Kompromiss.
So richtig toll ist das nicht
Das heißt, wenn wir jetzt nochmal gucken, wenn wir auf Programmiersprachen schauen,
dann sind die Objekte in Programmiersprachen abgebildet als Typen.
Das heißt, wir modellieren Objekte, indem wir Klassen definieren,
von denen wir Exemplare erzeugen können.
Die Exemplare sind dann die Objekte. Jede Klasse definiert einen Typ,
das habe ich schon mehrfach gesagt,
und die Operationen der Klasse sind dann die Operationen des Typs.
Die Exemplare einer Klasse bilden, extensional,
also das ist so ein Begriff im Sinne von,
die Menge aller Exemplare bildet die Elementmenge eines Objekttyps,
dann nennen wir das jetzt hier sofort
die Elementmenge
Vielen Darstellungen werden so, wenn man über Typen redet wird,
von Wertemenge gesprochen. Wir nennen das hier Elementmenge,
weil wenn man jetzt gerade, wir sind jetzt hier so dabei,
Werte und Objekte sehr genau zu unterscheiden,
dann wäre es irgendwie komisch von Wertemenge zu sprechen.
Quatsch. Also auch bei Objekten würde man dann sagen,
es ist eine Elementmenge, man könnte sagen, es ist die Objektmenge,
aber wir nennen es jetzt einfach mal die Elementmenge.
Und bei den Werten ist es halt so,
wir haben da sowas wie ganze Zahlen, Wahrheitswerte,
vordefiniert in Java, da gibt es Werttypen dazu,
die Elementmenge, dieser Typen ist unveränderlich.
Das ist ganz interessant. Bei den Objekten Typen ist es so,
ich kann beliebige Objekte erzeugen und die können auch wieder vergehen,
haben ja eine Lebenszeit.
Das heißt, die Objektmenge eines Typs ist dynamisch.
Bei Wehrtypen ist die unveränderlich. Ich erzeuge keine Werte,
also ist die Menge aller Werte konstant.
Die sind einfach da. Auch die Elementmenge ist sozusagen unveränderlich.
Bei In zum Beispiel sind es 2 hoch 32 Elemente.
Bei Boleen sind es genau zwei. Das heißt, auch
die Elementmenge ist unveränderlich bei Wehrtypen. Wir reden ja jetzt
über Wehrtypen in Programmiersprachen. Was ein weiterer Punkt ist,
wenn wir über Werte reden und auch die Programmiersprache abbilden,
dann reden wir nicht mehr von Konstruktoren.
Also ungern von Konstruktoren, weil ein Konstruktor,
eigentlich haben wir immer gesagt, Konstruktoren erzeugen ja nicht was,
aber Konstruktion steckt da irgendwie drin.
Zumindest initialisieren sie ja den Zustand eines neu erzeugten Objektes.
Das ist bei Werten aber ziemlich komisch,
weil Werte haben ja keinen Zustand, werden nicht erzeugt,
irgendwie doof dann zu sagen, ein Wert wird konstruiert.
Deswegen sollten die Operationen, mit denen wir auch Werte zugreifen,
sollten wir lieber Selektoren nennen, zum Beispiel.
Sie selektieren einen Wert aus der Menge der Werte,
die schon immer da sind
Gut, jetzt mal so kleine Bilanz nochmal.
Ich habe schon vorhin gesagt, wer hat abstrakt,
immer, abstrakt, zeitlos, unveränderlich.
Objektzustandsbehaftet in Programmiersprachen dann definiert über Werttypen. Da haben wir
eine unveränderliche Elementmenge. Es kaum einfach keine dazu, weil
ich keine Werte erzeugen kann. Und man hat dann sowas
wie Selektoren, um auf die Elemente des Typs zuzugreifen.
Bei Objekttypen ist es so dynamische Elementmenge,
Objekte können kommen und gehen. Und Objekthypen bieten Konstruktoren an,
um über sie dann Elemente erzeugen zu können
Was bei beiden gemeinsam ist, ist, ich kann also
sagen, ein Typ, das ist sozusagen generell gültig.
Ein Typ ist eine Elementmenge plus die Operationen auf diesen Elementen.
Das haben wir schon seit Anfang an hier so in SE1,
in SE2 vermittelt. Und das bleibt auch konstant so,
sowohl für Werttypen als auch für Objekttypen.
Und was man auch haben kann, zumindest in OO-Programmiersprachen,
ist Variable des Typs. Ich kann eine Variable deklarieren eines Typs,
und kann dann dieser Variablen einen Wert zuweisen,
wenn es eine Wertvariable ist oder ein Objekt,
wenn es ein Objekt variabel ist
Das heißt also, das muss man unterscheiden,
ob ein Wert an sich unveränderlich ist oder ob eine Variable
mit verschiedenen Werten belegt sein kann.
Das ist auch eine Sache, die gerne so ein bisschen
vermischt und durcheinandergebracht wird. Es gibt dann durchaus auch Programmiersprachen,
denen dann auch die Variablen nur einmal belegt werden können.
Das ist zum Beispiel in Skala möglich. Okay,
ich habe vorhin gesagt, Werte, Objekte unterscheinbar,
Objekten können wir unterscheiden zwischen Gleichheit und Identität.
Das ist dann hier nochmal so Bei der Gleichheit wird das
ja nochmal ein bisschen deutlicher. Also in Java,
wenn ich frage, was bedeutet A gleich gleich B?
Dann ist die nicht so einfach zu beantworten, die Frage,
weil ich nicht weiß, was für ein Typ A und B haben.
Wenn ich hier sowas habe wie A, gleich B,
also B wird A zugewiesen und dann sage ich FA gleich B,
dann weiß ich A 42 zu und B 42 zu und hinterher würde ich halt erwarten,
dass dann immer noch gilt A gleich gleich B.
Das ist bei Werttypen, wenn das In ist,
zum Beispiel als Typ, der der Variablen,
dann passt das, dann erwarten wir das.
Bei Strinks ist das aber ein bisschen anders,
haben wir jetzt schon das Beispiel gesehen,
also ich kann durchaus zwei Strinks haben, eigentlich gleich sind,
aber eben nicht identisch im Sinne von, es sind verschiedene Stringobjekte.
Blöd in Java. So, das ist ein bisschen unterschieden
ist. Ganz allgemein ist es so, man kann,
wenn man auf Gleichheit guckt von Objekten,
also wenn man einfach mal überlegen will, wann sind zwei Objekte gleich?
Dann kann man das zum einen sehr technisch betrachten.
Da gibt es also auch eine Publikation dazu,
die das mal sehr schön so in diesem Stil hier so auseinandergezogen hat.
Also es gibt einmal die Identität, das heißt also ich habe zwei Variablen,
die Objekte halten oder Referenzen auf Objekte.
Und wenn sie auf dasselbe Objekt zeigen, dann haben wir Identität.
Also zwei Variablen zeigen oft dasselbe Objekt
Und das ist dann die Referenzgleichheit, Identität.
Oder ich habe sowas wie einfache, strukturelle Gleichheit,
sowas hier, wie bei dem Beispiel C und D,
die sind sozusagen auf der obersten Ebene,
sind die gleich und dann zeigen sie an die tieferen Ebenen auf dieselben Objekte.
Das ist ja durchaus was, was ihr in Java schon gesehen habt.
Und dann gibt es aber auch sowas wie rekursive,
strukturelle Gleichheit, also wirklich bis ins kleinste Detail sind,
alle Unterelemente auch gleich.
Und es ist klar, dass die Identität impliziert,
dass man auch eine flache Gleichheit hat, eine einfache,
strukturelle Gleichheit.
Und das wiederum impliziert,
dass das dann auch tiefgleich ist
Ja, so kann man also, es gibt tatsächlich Programmiersprachen,
in denen dann diese verschiedenen Formen von Gleichheit implementiert sind.
Weil die kann man bauen. Da kann man einfach in der Sprache was anbieten,
wo dann diese Bäume da travisiert werden zur Laufzeit und
dann geguckt wird, ob Dinge gleich sind.
Igar Biver, ja, kann man alles anbieten.
Aber die Frage ist immer, wie nützlich ist denn das, diese Gleichheit?
Diese technische Gleichheit, wann Objekte irgendwie gleich sind,
ist zwar interessant, aber dann ist es nicht ausreichend,
weil man hat ganz oft einfach so eine semantische Gleichheit.
Also ich möchte einfach entscheiden für bestimmte Situationen,
wann zwei Objekte als gleich angesehen werden.
Diese mit den Büchern, Es kann sein,
dass zwei Bücher in der Bibliothek das gleiche Buch darstellen.
Das sind wirklich die gleichen, das ist der gleiche Inhalt,
haben aber verschiedene ISBNs. Für mich sind die gleich. Ob da,
wenn da jetzt drei Bücher im Bestand sind und ich kann mir nur eins ausleihen,
ist es mir wurscht, welches von den dreien ich ausleihe.
Aus meiner Sicht ist es egal. Aus Sicht der Bibliothek natürlich nicht.
Die haben dann die ISBN und dann irgendwie eine laufende Nummer.
Also sind es verschiedene Objekte. Das heißt,
das Licht im Auge des Betrachters, wann Dinge gleich sind.
Es gibt nicht sowas wie eine universelle Beantwortung und der Frage,
wann sind zwei Objekte gleich
Sehr, sehr semantisch. Sehr, sehr anwendungsabhängig. So,
klar, dann sagen die Leute, die jetzt Java gut kennen,
naja, ist doch klar. Deswegen, weil ich ja weiß,
dass es irgendwie keine klar vorgegebene Gleichheit geben kann,
kann man ja in Java das Equals-Rede definieren.
Ist doch super, da kann ich auch meine eigene semantische Gleichheit festlegen.
Ja, nobal. Aber so richtig die Lösung ist das
auch nicht, weil das hat ja so einige Probleme.
Also das habt ihr schon teilweise möglicherweise mitbekommen.
Erstmal ist das Equals asymmetrisch. Ja,
bin ich zwei Objekte, also ich habe zwei Referenzen,
wenn ich die miteinander vergleiche, ist es nicht egal,
ob ich frage A,
Equals B oder B,
Wenn einer von beiden nalles geht es im einen Fall schief,
im anderen Fall könnte es gut gehen.
Wenn das die neue Referenz als Parameter übergeben wird, geht es gut.
Wenn ich an einem Nall-Objektaufruf für Equiels, gibt es eine Null-Pointer-Acception.
Das ist also schon mal ziemlich hässlich.
Das ist dieser Vergleich mit Nall ist sowieso immer schwierig.
Welchen Typ hat der Parameter? Ihr wisst, in Java
ist es so, bei Equiels ist der Parameter-Typ Object.
Haben die irgendwann mal festgelegt für die Sprache, damit beliebige Objekte
miteinander verglichen werden können. Führt aber zu diesen hässlichen Downcasts,
diese Vergleiche von Dass man also erst mal feststellt,
ist das ein Exemplar meiner Klasse, also ein Typ-Test,
dann macht man eine Typ-Zusicherung und dann, das kennt ihr das Spiel.
Ziemlich hässlich, ziemlich komisch eigentlich. Gab es aber so Leute wie Bettrommel,
jeder hat das in Eifel, hat das dann anders gemacht.
Der hat dann gesagt, okay,
wenn ich sowas habe wie Person und ich habe ein Equals für Personen,
dann ist der Parameter von Personen nicht Personen festgelegt,
sondern ich sage einfach, der Parameter von Equals ist like Carrent.
Das heißt, so viel wie, das ist der Typ dieses dieser Klasse.
Also in der Klasse gibt es eine Operation Equals,
die Klasse heißt Person, also ist dann like Carrent,
hier logisch interpretiert dann Personen.
Wenn ich dann aber einen Student habe, der von Personen erbt,
dann wird bei Equals automatisch jetzt als Parametertyp,
weil das ja wieder like courrent ist,
ist dann hier der Typ des Parameters Student.
Ich kann also nur dann Studenten miteinander vergleichen und nur Personen miteinander vergleichen.
Waren da irgendwie erstmal attraktive Idee, das hatten wir leider
dazu geführt, dass das Eifel nicht statistypsicher war.
Ich habe ja irgendwann vor ein paar Wochen mal was erzählt über Co-Variante,
Parametertyp-Anpassungen und das ist genau so ein Fall,
wo das eben halt gegen die Wand fährt.
Das funktioniert leider nicht
Also das ist so eine Sache mit der Gleichheit.
Und dann haben wir nochmal hier so Gleichheit in Theorie und Praxis.
In der Mathematik wisst ihr einfach, Gleichheit ist reflexiv, symmetrisch und transitiv.
Also A ist immer selbstgleich zu sich selbst. Dann,
wenn A, Gleiches zu Bedern ist, Bier auch gleich zu A.
Das ist ja schon in der Programmiersprachenwelt ein bisschen anders.
Und wenn Gilt A ist gleich B und B ist gleich
C, dann gilt auch A ist gleich C.
Das ist in der Mathematik sozusagen postuliert. In Java sieht das
ein bisschen anders aus, wenn wir gerade hier so uns angucken,
sowas wie hier Intager A ist gleich 128.
B ist auch 128 und C ist auch 128.
Dann wird hier dem Intager der Referenz, ein Objekt zugewiesen.
Also hier wird die 128 vom Compiler hinter den Kulissen eingepackt,
in ein Interjour-Objekt und zugewiesen.
Also A, halt eine Referenz auf die 128. B,
ist dann wirklich 128 und C,
ist dann wieder eine Referenz und dann gilt A,
ist gleich gleich B und B ist gleich gleich C.
Das ist tatsächlich so, weil dann der Compiler dafür sorgt,
dass wenn A mit B verglichen wird, das A ausgepackt wird.
Da habe ich das A ausgepackt, damit dann die Werte miteinander verglichen werden können.
Bei B und C ist das auch so,
aber bei A und C ist es nicht so.
Also das sind so Sachen, die sind einfach ein bisschen unglücklich.
Da gibt es also einige Sachen, die unschön sind,
Was auf jeden Fall nochmal wieder wichtig ist,
was ich eigentlich jetzt ja hier so ein bisschen versucht habe zu verdeutlichen.
Es gibt einen Unterschied bei Objekten zwischen Gleichheit und Identität.
Und der fällt uns teilweise dann in Programmiersprachen auch auf die
Füße, wenn wir wertartige Dinge modellieren wollen.
So, das heißt also, hier haben wir jetzt ein
paar Objekttypen nochmal dazu bekommen, unterscheiden Gleichheit und Identität.
Und dann haben wir hier letztendlich nochmal die, die gemeinsam sind.
Gut, ein Punkt noch hier, unverhinderliche Objekte,
ich habe die vorhin schon erwähnt,
in vielen Kontexten ist es durchaus sinnvoll, änderliche Objekte zu modellieren.
Also wird also ganz häufig gesagt, wieso, warum brauche ich denn Werte?
Ich kann doch einfach unveränderliche Objekte nehmen. Aber es ist
tatsächlich ein Unterschied zwischen einem Wert und einem unveränderlichen Objekt.
Also zum Beispiel in so einer Filmdatenbank kann man hier sagen,
ein Film wird erzeugt, mit Hitleregisseur und Filmlänge und so weiter.
Und danach ist das Ding unveränderlich. Es wird also einfach
irgendwo abgelegt und diese Filmobjekte sind dann einfach nicht mehr zu ändern.
Dann ist aber trotzdem ganz wichtig, der Film wurde irgendwann
mal erzeugt. Es gibt einen Erzeugungszeitpunkt für den Film
Und das gibt es bei Werten eben nicht. Hat man
nicht so eine Idee von, wann er erzeugt wurde.
Das heißt also, alle Eigenschaften eines Wertes müssen erfüllt sein,
damit man wirklich einen Wert hat. Das heißt,
so ein Film, der zwar unveränderlich ist in einer Modellierung,
ist deswegen noch lange keinen Wert.
So, und das ist jetzt hier sozusagen der wehmütige Blick in die Zukunft.
Da sind wir noch nicht. Wir sind unter anderem mit so
ein bisschen unserer Forschung auch da dran, zu festzustellen,
was macht denn so Werttypen aus und wie kann man denn Werttypen in einer Programmiersprache gut unterstützen?
Und was wir halt postulieren wäre,
das ist tatsächlich in zukünftigen Programmiersprachen nicht nur Konstrukturen gibt für Objekttypen,
sondern auch gleichberechtigt, daneben Konstrukturen für Werttypen.
Und diese Werttypen, da müssen dann bestimmte Eigenschaften garantiert werden
von der Sprache, vom Compiler. Das ist also die Wertemenge,
fixiert ist, also festgelegt ist unveränderlich,
dass die Elemente auch unveränderlich sind und zwei Eigenschaften,
die wir jetzt hier wenig besprochen haben,
dass die Operationen referenziell transparent sind und keine beobachtbaren Seiteneffekte haben.
Das sind zwei Eigenschaften, die in der funktionalen Welt sehr,
sehr stark gefordert werden, in pur auf funktionalen Sprachen.
Ist das einfach so? Und es hat Vorteile,
wenn das so ist. Man hat Vorteile davon,
wenn diese Eigenschaften erfüllt sind
Und die können aber üblicherweise in den meisten Objektfunktionalen
Sprachen nicht garantiert werden. Wenn ihr euch Skala anguckt,
dann könnt ihr an allen Stellen alles machen.
Man hat überhaupt keine Garantien, dass bestimmte Operationen wirklich referenziell transparent sind.
So, und dann ist eben halt auch eine wichtige Eigenschaft.
Eigentlich sollten Werttypen sich nur auf Werttüten beziehen.
Das ist auch wieder so etwas Ehrwürdiges wie ein Werttyp,
die zahlen zum Beispiel, das wäre jetzt komisch,
wenn ein Werttyp definiert wäre auf Basis von Objekttypen,
weil Objekttypen haben ja auch Zeugungszeitpunkte und ähnliches.
Also es wäre relativ komisch
Da sind wir noch weit von weg. Wir haben auch mal
eine experimentelle Programmiersprache als Dialekt von Java definiert, die solche Werttypen drin hatte.
Spannendes Zeug finden, es interessiert irgendwie mal in späteren Semestern.
Was wir jetzt in den letzten zehn Minuten nochmal uns angucken,
ist, wie wir denn Werttypen ganz pragmatisch mit den Wertklassen von Java bauen.
Also wir haben so eine Sprache wie Java,
die ist einfach nach wie vor eine Sprache der Wahl für uns, für Softwareentwicklung.
Oder andere ähnliche Objektantitel sprachen. Und jetzt ist die Frage,
wenn ich sowas bauen will wie ein Werttyp,
wenn ich also wirklich diese Eigenschaften von Werten in der Sprache,
wie kann ich das denn machen mit den Mitteln von Java?
Gut, in Java habe ich nur Klassen für Objekte.
Aber wenn wir jetzt sozusagen mit den Objektklassen Werttypen bauen wollen,
dann nennen wir die ab sofort Wertklassen.
Also die Klassen, mit denen wir Werte bauen,
die nennen wir Wertklassen. Und jetzt gibt es ziemlich viele Programmiermüster,
die uns dabei unterstützen, solche Single zu tun,
wie man also sozusagen in einer OO-Sprache Werttypen bauen kann.
Ein Beispiel ist das Type-Safe-Een am Pattern von Bloch,
das ist in diesem Buch beschrieben
Das ist tatsächlich das, was hinter den Enums von Java steckt.
Hinter den Kulissen ist genau das verbaut. Also wenn ich
in Java jetzt schreibe, eh nur Farbe mit rot-grün-blau,
dann wird hinter den Kulissen so was draus gemacht, mehr oder weniger.
Ich kann also hier eine klasse Farbe definieren und kann
den Konstruktor der Klasse Private machen. Das führt dazu,
dass ein Klient keine Exemplare dieser Klasse mehr erzeugen kann.
Ja, und dann kann ich aber öffentliche Klassenmethoden, öffentliche Klassenkonstanten definieren, hier rot-grün-blau.
Das sind dann die einzigen Möglichkeiten an Objekte dieser Klasse heranzukommen.
So habe ich dann tatsächlich nur drei Exemplare dieser Klasse,
die ich nur innerhalb der Klasse erzeugen kann,
weil wenn ein Konstrukt da private ist,
kann ich halt nur in der Klasse ihn auch benutzen.
Und dann kann ich tatsächlich dadurch garantieren, dass es nur
genau drei Exemplare gibt und ich auch sogar diese Exemplare über Referenzgleichheit vergleichen kann.
Also sobald ich eine Variable habe von dem Typ Farbe,
kann da entweder eine Referenz drin sein, auf rot,
auf grün oder auf blau.
Und ich kann die Referenzen wirklich mit Referenzgleichheit vergleichen.
Das ist ziemlich toll. Dummerweise sind die Enums in Java keine echten Werttypen,
weil ich kann damit auch wieder, Also die Elemente von diesem Typ,
der hier definiert wird, also rot, grün und blau,
die könnten jetzt auch einen Zustand haben.
Man kann in Java da bei den Enums auch durchaus Zustände mit reinbauen.
Also sind das dann irgendwie Aufzählungen von Objekten allgemein. So,
und deswegen haben wir so ein paar Richtlinie jetzt hier,
wie man Wertklassen in Java bauen kann,
mit den Bordmitteln von Java.
Das sind hier sozusagen sechs relativ einfache Regeln. Die Regeln sind,
also ich möchte, dass Wertobjekte keinen veränderbaren Zustand haben,
dass Werte und Wertobjekte
sich nicht auf Objekte beziehen
Also keine Referenzen halten auf Objekte oder ähnliches. Dass im Quelltext einer Wertklasse
keine bestehenden Objekte verändert werden, auch keine anderen Objekte, die irgendwie...
Und dass dann auch die technisch notwendige Erzeugung von Wertobjekten eigentlich
verborgen werden sollte. Dass man also nicht New-Kontonummer schreiben muss,
weil das sieht so aus, als wenn würde eine neue Kontonummer erzeugt,
aber eigentlich ist es ja nur ein Zugriff auf die Kontonummern,
die schon alle da sind.
Wäre also schön, wenn man das ein bisschen verstecken würde.
Und was vor allen Dingen wichtig ist, wenn man Equiels richtig findet,
das ist etwas, was man gerade bei Werttypen tut.
Ich habe ja die These, dass man eigentlich es nur bei Werttypen Typen macht,
dass man Equals redefiniert, aber wann immer man das tut,
dann muss man auch passend dazu Hash quo drehen, das wisst ihr.
Und dann, wenn ich sozusagen die Weltklasse so konstruiert habe,
dann ist eben halt die Sache,
dass man als Klient in Java immer Equals statt gleich gleich benutzt.
Wenn ihr das jetzt überlegt, bezogen auf String ist das tatsächlich so,
also Wertobjekte haben keinen veränderbaren, also die Strings haben keinen veränderbaren Zustand,
Werte und Wertobjekte beziehen sich nicht irgendwie auf Objekte,
das ist bei String auch relativ gut eingehalten und die Erzeugung von Wertobjekten ist tatsächlich verborgen,
dadurch, dass man einfach so ein Stringliteral hinschreiben kann.
Man schreibt selten News-String, kann man auch machen,
aber muss man oft nicht. Gut, gucken wir uns
im Detail nochmal ganz kurz an. Einfach nochmal im Sinne von,
was muss man denn tun und wie gut ist die Sprachunterstützung dafür?
Also wenn wir sagen, die Objekte einer Wertklasse sollen unveränderlich sein,
dann kann man das gut machen mit dem Schlüsselwort Final.
Ich kann tatsächlich sagen, alle Zustandsfelder sollen Final sein,
dann kann ich die einfach nicht verändern,
dann können die nur einmalig im Konstruktor gesetzt werden.
Und ich kann tatsächlich auch die ganze Klasse Final machen,
Dann ist es in dem Sinne,
dann ist es nicht mehr möglich, eine Unterklasse zu bilden.
String ist tatsächlich so ein Beispiel. Ich kann keine Unterklasse von String bilden.
Ich kann also nicht sozusagen Polymorph einen veränderbaren String unter eines Dringbarriabelschummeln.
Geht einfach nicht. Das ist ganz clever gemacht.
Dann Wertobjekte sollen sozusagen Blätter im Objektbaum sein.
Das sollen also, es soll keine Referenzen geben von Wertobjekten
auf Objekte
Sprachunterstützung dafür gibt es gar keine, gibt es einfach keine Garantie in Java.
Das heißt, man muss das alles selbst beachten. Das heißt,
in einer Wettklasse sollten die Typen aller Zustandsfelder nur Werttypen sein.
Also entweder primitive Typen oder eben halt andere Wertklassen.
Das dringen, wie gesagt, habe ich schon gesagt,
kann genau als so eine Wertklasse angesehen werden.
Dann keine bestehenden Objekte verändern. Das ist etwas,
was einfach gut ist, wenn das passiert.
Auch da gibt es keinerlei Garantien. Die Sprache gibt keine
Unterstützung. Das heißt, man muss selber darauf achten,
dass im Quelltext einer Wettklasse keine Objekte verändert werden,
dass keine Objekttypen als Parametertypen in der Schnittstelle auftauchen von
einem Werttyp
Und was man manchmal zulassen kann, ist im Rumpf einer Methode,
das so für so Zwischenberechnungen auch mal vielleicht Objekte erzeugt werden, aber nur so zwischendurch.
Das heißt, da geht nichts über die Schnittstelle rein oder raus. Gut,
Erzeugung verbergen, das ist etwas, was tatsächlich in den Werttypen,
die wir auch in den Projekten,
die wir euch vorgeben und nicht verbaut haben,
habe ich jetzt wieder festgestellt, klassisch macht man das dann dadurch,
dass man, habe ich ja eben schon gezeigt,
dass man den Konstruktor verbirgt, privat macht und dann Fabrikmethoden anbietet.
Also einfach eine Methode, eine statische Methode, wo man sagt, select oder irgendwie
Gib mir doch mal jetzt einen Wert aus dieser Wertemenge.
Diese Methoden würden dann praktisch Detektoren werden. Und wenn man das macht,
dann kann man auch eventuell auf Regel 6 verzichten.
Bei dem Type-Safe In am Pattern haben wir gesehen,
ich muss gar nicht immer mit Equals vergleichen,
weil auch der Referenzvergleich da funktioniert.
Aber das ist selten konkret der Fall.
Gut, und Equals und Hashcore implementieren ist ganz wichtig.
Das wisst ihr, wenn man das tut,
dann muss man auch Hashcode entsprechend passend dazu implementieren.
Das heißt, wenn zwei Wertobjekte, die als gleich gelten,
dann müssen die auch denselben Hashcode liefern.
Auch da gibt es keine Sprachunterstützung,
da müsst ihr einfach entsprechend darauf
selber achten
Das sind alles so Dinge, die ganz viel
auch in der Programmiersprachen-Community diskutiert worden sind die letzten Jahre.
Also dieses Equals und Hashcode ist ja nicht einfach,
dass das auch passend zueinander definiert wird.
Wie kann man denn sozusagen das verhindern,
dass man das als Programmierer falsch machen kann?
Und das ist so ein Ansatz,
dass man sowas eigentlich gerne in der Programmiersprache abgelegt hätte.
Wie gesagt, im Java ist es nicht so.
Gut, dann sind wir auch schon fast am Ende.
Ich habe jetzt hier nochmal versucht, diesen Unterschied zwischen Werten
und Objekten euch klarzumachen. Ich habe halt versucht,
Leute zu machen, dass die es wirklich
fundamental verschiedene Dinge sind
Ja, also zustandsbehaftete,
vergängliche Gegenstände und Konzepte lassen sich gut als Objekte modellieren.
Während man so zeitlose, unveränderliche Größen eher als Werte darstellen sollte.
Die These, die wir hier vertreten, ist,
dass solche fachlichen Werte in vielen Anwendungszusammenhängen eine Rolle spielen und auch modelliert werden sollten.
Und das Objektentitel sprachen dummerweise ziemlich gut sind,
solche Klassen zu definieren, die Objekte machen,
aber Benutzer definierte, fachliche Werte sind relativ schwach unterstützt.
Okay, dann machen wir jetzt nochmal hier
so eine kleine Storesi-Geschichte
Hier, so zum Üben. Welche
der folgenden Aussagen zu werten, im Gegensatz zu Objekten,
also welche Aussage zu werten und wer Typen ist falsch.
Aufpassen, doppelte Verneinung. Also welche der Aussagen,
es war drei Aussagen sind richtig und nur eine ist falsch.
Die erste Aussage ist, Werte sind zeitlos,
die zweite Aussage ist, es gibt genau eine Repräsentation für einen Wert.
Die Aussage C, ein Wert kann nicht kopiert werden und die Aussage,
die, die primitiven Typen in Java sind,
Welche diese Aussagen ist falsch?
Na, ich bestimme hatten wir eigentlich eben
Aber über 30 hatten wir eben schon, wenn ich mich recht erinnere.
Gut, 30 stellen wir schon mal ganz gut.
Da kriegen wir schon mal so ein ganz gutes Meinungsbild.
Falls ihr euch noch nicht entschieden habt, tut es jetzt noch.
Okay. Ja, so, jetzt sieht man hier schon,
dass das durchaus, also ich habe anscheinend zu schnell gesprochen,
die Mehrheit ist dafür,
es gibt genau eine Repräsentation für einen Wert,
dass das
eine falsche Aussage ist
Einige, eine Person sagte, Werte sind Zeitus,
das wäre eine falsche Aussage. Werte sind natürlich zeitlos,
das habe ich relativ früh schon gesagt hier.
Die primitiven Typen in Java sind tatsächlich Werttypen,
auf jeden Fall ist das eine richtige Aussage.
Und naja, zwischen den beiden hier ein Wert kann nicht
kopiert werden, das hatte ich auch deutlich gemacht.
Also dass es irgendwie komisch ist bei Werten von Kopien zu reden,
das heißt, die richtige Antwort ist hier tatsächlich B. Okay,
dann habe ich hier noch eine etwas leichtere,
welche Aussagen zu Objekten,
wie gesagt,
zu werten ist falsch
Wieder jetzt doppelte Verneinung möglich. Also Objekte existieren in
den Raum und Zeit. Ist das richtig oder falsch?
Objekte können unveränderlich sein, richtig oder falsch.
Zwei gleiche Objekte sind automatisch auch identisch oder die Objekte sind
potenziell veränderbar
Ja. Okay, wir sind wieder bei 30 Stimmen, sehr schön.
Ich halte das mal an, oh, 33, wunderbar.
Ja, gucken wir mal, wie auf die Verteilung.
Ich bin stolz auf euch. Das ist die richtige Antwort
. Das habe ich noch nicht gesehen,
also 100 Prozent Bernstark
Ja, okay,
dann entlasse ich euch mit einer eigenartigen Diskussion zu,
was sind Werte und Objekte und viel Spaß in
den weiteren Übungen.