Wir haben festgestellt,
dass Werte und Objekte noch ganz unterschiedliche Eigenschaften haben,
aber unsere Welt, unser Mittel der Implementierung,
ist nun mal Objekte und hier der Programmierung, objektuentierte Programmiersprachen.
Das heißt, wir müssen irgendwie versuchen, das mit objektorientierten Programmiersprachen abzubilden.
Das ist unser Thema in diesem Abschnitt. Und wir müssen da sehen,
dass wir doch, dass es wir durchaus schaffen,
quasi unveränderliche Objekte mit unveränderlichen Objekten zu arbeiten.
Eben filmtilt Regisseur und so weiter,
das ist unveränderlich für einen Film in unserer Medienbibliothek
Auch wenn wir da ein Objektklasse haben, wo Eigenschaften vergeben werden.
Aber wenn wir nur sondierende Operationen abgeben, also nichts veränderndes,
ist das da nicht quasi ein Wert? Nein,
wir müssen versuchen, wir sollten versuchen, auch jenseits dieses Beispiels,
alle Eigenschaften eines solchen Wertes in dem Ding unterzubringen.
Und deswegen nicht nur eine solche Eigenschaft. Natürlich wäre es wünschenswert,
wenn wir irgendwann mal Sprachen hätten, für die diese Werte existieren.
Da müssen wir nur noch dafür sorgen,
dass die Entwickler diese neuen Konzepte auch anwenden,
aber nehmen wir mal an, wir könnten das anbieten,
dann würden wir dann sagen, okay, ja,
die Wertemenge ist fixiert, wunderbar, die Elemente sind unveränderlich, wunderbar.
Die Operationen sollen referenziell transparent sein, also keine Seideneffekte haben.
Und wir sollten uns bei der Definition nicht auf Objekte stützen,
sondern nur auf andere Werttypen, also auch die Benutzungshierarchie und die Vererbungshierarchie sollte dort entsprechend geklärt sein.
Wunderbar wäre das. Diese Welt ist nicht so,
es gibt die realen Programmiersprachen, nehmen wir mal als Beispiel CPlus,
plus CSharp, dort haben wir Structs, das in deinen Strukturen,
die wie Objekte verwendet werden können, aber ein paar Eigenschaften von Werten haben.
Ja, also sie können Zustandsvariablen Methoden definieren,
sie können erzeugt werden, ihre Elemente sind veränderbar,
soweit, das ist das, was wir eigentlich nicht wollen,
aber wir wollen ja Werte haben,
sie sind wirklich nur die Referenzen dort drin,
ja, bei Parametern wird wirklich eine Kopie erzeugt,
das erzeugt Unabhängigkeit von Minderzeiteneffekten und wenn wir da drin Konstanten haben,
dann sind die auch wirklich konstant.
Wie können wir das machen, wir können Java mit verwenden,
mit Werttypen mit Benutzer definierten Wehrtypen und dass er quasi selbst definieren,
das möchte ich Ihnen jetzt vorstellen.
Und zwar, dass Type safe in einem Pattern,
ja, in einem für Innovations, für Aufzählungstypen,
ja, es gibt noch weitere Programmiermuster,
über die FTV hier in dieser Veranstaltung nicht eingehen,
ich stelle Ihnen das eine vor, das ist auch wieder ein Entwurfsmuster.
Dieses Entwurfsmuster geht eigentlich über Aufzählungstypen,
wir können die Typs sicher in Java modellieren,
diese Aufzählungstypen, an die Beispiele von vorhin denken,
zum Beispiel dass wir Bankleitzahlen haben.
Ja, die Menge aller Banken, da gehört die Menge aller Bankleitzahlen dazu.
Das kann ich durchaus fürs Aufzählungstyp machen. Ja,
und das Grundmuster ist, dass es ein Public-Style-Assattic-Final-Feld gibt.
Final kennen Sie schon, das sind Sachen,
die man nicht mehr verändern kann.
Das können Sie schon erwarten, dass wir sowas ja brauchen.
Für jede Konstante dieser Aufzählung benutzt man also eine solchen Modifikator.
Und wir verstecken den Konstruktor, dass keiner damit was erzeugen kann.
Und schon haben wir noch eine weitere Objektanschaft erreicht
Tatsächlich gibt es Inums in Java seit Java 1,5,
da ist dieses Muster drin. Ja,
allerdings können wir da einen veränderlichen Zustand doch noch erreichen.
Es entstehen wert, Objekte. Das könnte durchaus auch sinnvoll sein.
Lassen Sie uns überlegen, wie können wir alle Eigenschaften,
die wir brauchen, für solche Wertobjekte schaffen.
Deswegen sechs wichtige Eigenschaften, ich nenne sicher Richtlinien,
dass wir Wertobjekte, Wertklassen schaffen können.
Erstens,
kein veränderbarer Zustand
Zweitens, sie beziehen sich nicht bei ihrer Deklaration,
sie selbst wieder auf Objekte,
die veränderlich wären und damit wir die Veränderlichkeit durch die Hintertür reingeschoben.
Wir im Quelltext selber verändern wir keine Objekte.
Also das heißt, wir haben nichts, wo wir irgendwie
auf den Zustand des Systems einwirken. Es gibt keine Erzeugung,
indem wir die verbergen und wir haben die Operation,
ich will es für Vergleiche, damit wir die Gleichheit entsprechend machen können.
Soviel für die Konstruktion, für das Erzeugen,
für die Deklaration und für die Benutzung von Wertklassen
nehmen wir immer Equals und nie ist gleich,
ist gleich
Soweit geben wir das noch einmal durch. Unveränderlicher Zustand.
Alle Exemplare sollten unveränderlich sein. Wir können Final verwenden.
Final ist, darf nur innerhalb des Konstruktors zugewiesen werden.
Oder beide Deklaration und das Final kann für die fast festgelegte
Wertklasse festgelegt werden. Wenn wir keine Subklassen brauchen oder erzeugen
wollen. Auf die Weise können wir verhindern,
dass jemand eine Subklasse erzeugt und in der Subklasse wieder irgendwas
macht,
was wir nicht wollen
Werteobjekte selber basieren, nicht auf anderen Objekten, ja,
also primitive, es wird kein, wenn keine Objekte davon abgeleitet,
wenn wir sagen, diesen Objektbaum,
da gibt es also keine Referenzen, auf echte Objekte.
Ja, da brauchen wir keine Sprachunterstützung,
wir müssen das selbst beachten, dass wir darauf sorgen.
Ja, so, wir verändern keine anderen Objekte,
das war die dritte Eigenschaft, ja, das müssen wir,
Sprachunterstützung gibt es dafür wieder nicht.
Es ist immer kritisch, wenn man nur,
dass sich auf die Disziplin der Entwickler verlässt. Ja,
es ist doch schöner, wenn das Programmiersprache oder der Compiler überprüft.
Aber in dem Fall geht es einfach nicht, weil es nicht vorgesehen ist.
Wir haben ja nur die Abschnitt mit der Wunschliste,
ja, zukünftige Programmiersprachen mögen doch.
Ja, die Realen haben es nicht. Ja,
also wir müssen das selbst beachten, dass wir keine anderen Objekte verändern,
damit wir nicht auf einen deren Zustand abhängen und deswegen ist hier gleich als Hinweis,
es sollten keine Objekttypen als Parametertypen erscheinen werden.
Ja, lokal kann man das zulassen, aber sonst nicht.
So, wir sollten die Erzeugung verbergen,
also es durfte keinen Konstruktor geben,
ja,
Konsunkt zum Beispiel Private machen
Ja, dann kann man nicht mehr direkt was erzeugen.
Oder wir machen Fabrikmethoden. Sie erinnern sich, Fabrikmethoden waren Methoden,
zum Erzeugen von Objekten. Ja, und die werden mit Static deklariert,
damit sie auch unveränderlich sind, hier verwendet werden können.
Und wir hatten vorhin den Begriff des Delektoren statt Konstruktoren.
Ja, so, wenn wir das haben,
ist die Regel 5 auch gleich mit erfüllt.
Und ansonsten Equals verwenden, um Gleichheit zu definieren. Das ist ganz wichtig,
damit wir diese definieren können, was ist denn wirklich gleich,
damit wir nicht mit dieser Identitätsfrage rumschlagen müssen, ja,
und der Herrn Hashkurt verwenden wir dabei.
Ja, und wenn wir das mal als Beispiel anschauen,
ach so, jetzt war das gerade dieses Type-Safe-In-Um-Pattern und die Prinzipien,
ich gehe mal ein bisschen zurück, das Type-Safe-In-Um-Pattern war nämlich Gegenstand der Frage.
Drei, älter Frage 5, hier erläutern Sie das und
dazu hatten wir Folie 37 des Pattern erklärt. Ja,
so wir waren aber schon zwei weiter und ich wollte,
nein, hier waren wir, wenn wir jetzt als Beispiel das nehmen,
wir wollen oder wo kommt sowas mal vor.
Zum Beispiel, wir wollen unsere SE-Bar erweitern, um Produkt-IDs. Diese Produkt-IDs sind dann,
haben den Charakter, zum Beispiel weil wir die aufkaufen,
sowas passiert ja bei Firmen immer mal,
wir müssen die in einem zentralen System führen und da gibt es irgendwie Regeln,
Diese Regel können sie auch sich gleich den Klammern dahinter schreiben.
Achtung, das ist der Werdebereich. Und hier gibt es
Gültigkeitsbereiche für verschiedene Untermengen der Produkte. Und mit diesen Dingen
könnte ich zum Beispiel nicht rechnen. Sie sind Identifikatoren,
ich kann sie nur zuweisen, nicht verändern, nicht erzeugen und so weiter.
Nur wenn ich in deinem Produkttyp mehr ausdenke.
Also alle Merkmale, die ein Werkzeug hat. Soweit dazu,
damit wir noch mal ein Beispiel haben,
wo ich denn das verwenden könnte,
Regeln 1 bis 6 bzw. 1 bis 5. Ja,
wir haben noch eine Frage offen, die möchte ich gerne mit Ihnen
In der Fragerunde diskutieren, nämlich die Frage 6,
wie würde denn das aussehen, wenn wir das für Postleitzahlen machen?
Das wäre, ja, also ich sage mal hier,
wir müssen diese Richtlinien umsetzen,
so viel sollten sie das direkt einfach wiedergeben können von den letzten paar Folien,
ja, also kein veränderbarer Zustand, nicht als Objekt behandelt.
Wir wollen das nicht verändern, Ergänzung irgendwie verbergen,
ich will es erzeugen, implementieren hat. Ja,
dass das alles soweit easy, wir müssen mal überlegen,
was machen wir da genau?
Und natürlich für die Benutzung E-Grads verwenden
Soweit dazu, die letzte Folie hat direkt nochmal Literatur dazu.
Ach nein, Hebammen sagt, die Zusammenfassung erstmal,
das hatten wir alles hier besprochen.
Wir haben diese fachlichen Werte als ein weiteres Konzept,
das man bei Modellierungen von technischen Systemen oder von Softwaresystemen gut brauchen kann.
Und hier gab es da nochmal Literaturquelle, wo sie dazu mehr weiterlesen wollen,
wenn sie was zu diesem Fach werden wissen wollen.
Ja, und wie gesagt, Einleitung zur Fragerunde,
da werden wir das hier diskutieren und gemeinsam eine Lösung finden