Wir haben also festgestellt, dass es die Möglichkeit gibt,
Werte, Werttypen in Objektorientierten Sprachen abzubilden.
Und wir haben festgestellt, dass man das anders machen muss,
als man das normalerweise mit Objekten macht.
Wir brauchen also eine unterschiedliche Behandlung. Und dabei müssen wir
halt aufpassen. In vielen Anwendungsgebieten brauchen wir das.
Gibt es die Möglichkeit oder gibt es den Bedarf für diese
1-zu-1-Abbildung der Realität, dass wir sowas wie Werttypen haben.
Also in unserem Beispiel, wie der Filmdatenbank,
ist der Titel oder der Regisseur oder sowas unveränderlich
Wir haben natürlich irgendwie den Film selber als Typ,
wir können das definieren, aber wir haben Exemplare, ja,
und da können wir auch etwas damit tun, aber ausschließlich lesende Operationen.
Ist das nicht sowas wie ein Wert? Da müssen wir wirklich ganz genau hinschauen und meistens gibt es da nicht unbedingt einfache Antworten. Man muss immer schauen,
was kann man damit machen, ja,
wir brauchen das nur für solche Operationen, ja,
aber ansonsten müssen wir sagen, nein,
das ist nicht wirklich ein Wert, das ist wirklich schon ein Objekt,
das Objekt hat einen Zustand, auch wenn das nicht nur,
wenn wir es so betrachten, dann vielleicht nicht,
aber ist es schon Verleih ist es schon,
ist der Film fertiggestellt,
ist er schon im Verleih oder ist er dann gar schon nach vier Wochen für TV freigegeben.
Das ist nicht so ganz unveränderlich. Man kann das abstrakt betrachten,
aber es hängt immer der Film ab, was ich damit machen möchte.
Wenn wir uns Objekte und hier zu sprachen gestalten könnten,
könnten, dann wäre die Frage,
sollte man nicht dafür separate Werttypen haben und ich möchte kurz,
und das ist dann der letzte Punkt von diesem Abschnitt,
noch darüber sprechen, was müssten das für Antwortungen sein,
weil daraus wird uns deutlicher, wird ihnen hoffentlich klarer,
was ist denn der Unterschied zwischen Objektin und Werte,
Objekttypen und Werttypen.
Also idealerweise würde die Programmiersprache das anbieten. Wenn die Opramie programmiersprachen,
das nicht anbietet, müssen wir es über Disziplin machen. Das heißt,
wir müssen bestimmte Regeln einhalten und diese Regeln einhalten,
das wäre, hier muss man hier von Hand machen,
während wenn wir dann auch noch mal Verzeihung,
eine objektorientierte Programmiersprache hätten, die das anbietet,
wäre das doch gut.
Ja, also die Wertemenge sollte in irgendeiner Weise fest sein.
Das hatten wir schon festgestellt. Wir Elemente sollten unveränderlich sein
Darüber sollte der Compilerwachen nicht etwa nur die Disziplin des Entwicklers.
Es sollte klar sein, dass diese Operationen zu keiner Veränderung führen.
Also wir nennen das ja Seideneffekte. Und wenn wir Werttypen definieren,
sollten wir das nicht auf Basis von Objekten tun,
sondern auf Basis anderer Werttypen.
Das wäre zum Beispiel eine Voraussetzung. Es gibt tatsächlich Elemente,
die sich von Sprachausdrücke, die dafür reichen,
zum Beispiel gibt es Structs in C plus Plus und sie schab,
die können wie Objekte verwendet werden,
die können
wie Werte verwendet werden
Ja, die Objekte, was Zustandsvariablen und Methoden betrifft,
sie können erzeugt werden und sie können die Elemente einer solchen Wertemenge von Structure ändern.
Aber sie haben auch Eigenschaften wie Werte, ja,
sie halten nicht die Referenz,
sondern tatsächlich den Wert eines Traktexemplars bei Zuweisungen,
Übergaben wird der Inhalt wirklich kopiert und wenn wir etwas konstantes
haben als Strukt,
dann kann es tatsächlich
den Zustand
nicht ändern
Wenn wir mit Java arbeiten wollen, gibt es leider eine
solche direkte Unterstützung durch die Programmiersprache und Überwachung durch den Compile-Unterstützung, durch dieses Laufsetzsystem nicht.
Wenn wir Wehrtypen definieren wollen, indem wir Objektklassen verwenden,
das ist das, was Java kann, was Java hat,
auch wenn wir das dann Wertklassen nennen wollen,
muss man selbst darauf achten, dass diese Werteigenschaften eingehalten werden.
Also dass dieses Einhalten von selbst, das ist immer das Problematische.
Und es gibt zum Glück ein paar Abhilfen, nämlich,
dass wir ein Muster verwenden können
Und jetzt wollen wir dieses Type safe in einem Pattern für Innomeration
hier behandeln. Das ist gleichzeitig bei einer der Fragen,
ihr da beiden, die Frage 5,
fragt sie genau nach dem, was jetzt, was jetzt kommt.
Das Tape safe, Tape safe innen, Pattern,
typsichere Aufzählungstypen, heißt das, ja,
das beschreibt etwas, das Nachbilden in Java.
Ja, das Grundmuster ist Public Static, Final,
was wir als Feld nehmen für die konstant deiner Aufzählung und gleichzeitig dem Konstruktur verstecken.
So bilden wir das letztlich nach. Das ist der Kern
dieses Type-Safe-In- und Patterns. Und wenn wir hier zum Beispiel
die Farbe als so etwas machen wollen,
ja, dann würden wir hier Public Static Final benutzen,
um die Werte zu definieren.
Ja, also wir haben hier einen Konstruktor tatsächlich,
aber wir sperren den Konstruktur. Wir verstecken ihn. Ja,
und dann bilden wir hier, definieren wir rot,
grün, blau,
als Werte
die Unveränderlich sind
Seit Java 1,5 gibt es Innums in Java.
Und die sind so realisiert. Denn allerdings,
und das ist jetzt der Punkt, Achtung,
man kann ja in den Exemplaren den Zustand zwar veränderlich den Zwischenveränderlich ebenfalls darstellen.
Und die Wertabjekte, die müssen durch Objekte repräsentiert werden.
So, wenn wir also sagen, ja,
aber unterstützt das nicht. Wir müssen es durch Disziplin machen,
sollten wir wenigstens so weit gehen, dass wir sagen,
okay,
wie geht's denn
Und das ist das jetzt auf dieser Folie. Und das ist dann
das, was wir in der Frage springen mal dahin.
In der Sprache Frage 6 hier nochmal behandeln.
Also diese Richtlinien zum ersten Wertobjekte dürfen keinen veränderbaren Zustand haben.
Wir müssen es irgendwie unterbinden. Werte und Wertobjekte dürfen sich
nicht auf Objekte beziehen. Das kriegen wir nur durch Disziplin
. Im Quelltext werden keine bestehenden Objekte verändert.
Und das Erzeugen müssen wir irgendwie verschwinden lassen, verstecken.
Das ist keiner aufrufen kann. Zusätzlich sollten wir Eakles entsprechend
und Hashcode so definieren, wie wir es hier brauchen.
Und dann müssen wir uns die sechste Regel nicht mit der Erzeugung
zu tun, sondern es ist eine Disziplin beim Verwenden.
Wir sollten nie diesen Istgleich, Istgleich als Gleichheitsoperator verwenden sollen,
immer eh kurz. Okay, diese Sachen,
schauen wir uns einzeln an, unveränderlicher Zustand.
Die Sprachunterstützung unterhilft da Feine. Und Final darf dann nicht
, darf der nur einmal beim Konstrukt dazugewiesen werden.
Und es gibt dann keine Unterklassen und so weiter.
Das damit verhindern wir Veränderungen
Die Werteobjekte sollten nicht von Objekten abhängen. Ja,
das heißt, die primitiven Objekte sind da schon drin.
Ja, und sonst konnte es keine Referenzen geben.
Die Sprache unterstützt es leider nicht, wir müssen das selbst tun.
Wir sollten keine wirklichen Objekte verändern, wenn wir mit Werten
arbeiten, auch dafür die Sprachunterstützung ist nicht vorhanden.
Wir müssen das selbst tun. Ja,
wir müssen selbst keine Objekte dürfen,
keine Veränderungen auf alle Objekten vornehmen,
innerhalb einer Wertklasse
Und wir sollten an der Schnittstelle keine Werte, keine Objekttypen als Parametertypen erscheinen.
Und wenn man doch mal was machen muss,
dann kann man irgendwas lokal definieren, wie stringen buffer.
Oder vom Metter oder sowas. Um vier Erzeugungen verbergen,
da soweit du das, keinen Konstruktor haben und so weiter.
Wir können das, die Konstruktur, können wir als Private deklarieren.
So, dann können wir auf Fabrikmethoden anbieten,
dass jemand trotzdem was erzeugen kann. Sie erinnern sich,
Fabrikmethoden war das, wo ich gleich ein ganzes Objekt Gepflecht erzeugen kann,
das irgendwie vorfertigen Und dann hätten wir tatsächlich das,
was wir vorhin Selektoren genannt haben, wir wählen einfach nur aus, aus verschiedenen Punkten.
Und so ist es möglich, dass wir die Regel 5 eigentlich gar nicht brauchen,
weil wir garantieren, dass es nur eine blickt, geben können.
Pro Equels Hashcoot, das ist das,
was wir von Yawai Ante von der Objektklasse erntet,
Object, dass wir können das nicht erzwingen,
wir müssen es nur selbst erwacht beachten,
indem wir immer für alle solche Werttypen Equels definieren,
das dann liefert,
wenn die gleich sind,
dann bekommen wir mit Equels
das Gleiche zurück
Kleine Übung. Wir wollen die Esseebar um Projekt-IDs erweitern.
Und das ist notwendig, nachdem wir organisatorische Änderungen haben.
Die SE-Bar wurde von jemandem, von einer größeren Kette gekauft.
Und jetzt müssen die Produkte im zentralen System auch noch irgendwie
aufgenommen werden. Und wir haben fünfstellige IDs. Ja,
wobei ein bestimmter Bereich für ihre Tränke reserviert ist,
im bestimmten Bereich für Essen im Betrieb stehen wir gleich für sonstige Produkte.
Und das müssen wir jetzt irgendwie aufnehmen. Dass unsere kleine
Aufgabe und damit sind wir am Ende dieses Abschnitts zu werden,
Wichtig nochmal, wir müssen im Kopf behalten,
es sind unterschiedliche Objekte, auch wenn wir unterschiedliche Konzepte,
sorry, unterschiedliche Inhalte, unterschiedliche Ansprüche,
auch wenn wir sie am Ende beide in die gleiche Objektualität der Programmiersprache abbilden.
Und bei dieser Abbildung müssen wir tatsächlich viel Disziplin halten lassen,
weil die Sprache das nicht unterstützt. Fachlich spielt das,
es ist eine große Rolle, spielt das eine große Rolle,
weil wir häufig solche unveränderlichen Werte haben.
Soweit zum Schluss und das war erst mal Werte und Objekte