Im zweiten Teil geht es darum, das zweite Prinzip der funktionalen Programmierung zu besprechen.
Nämlich veränderliche Objekte. Wir starten hier mit einem Zitat Multiple Objects all the news,
Spaghetti Code und in diesem kleinen Video können Sie sich anschauen,
wer das gesagt hat, in welchem Zusammenhang,
auch sehr interessant bezüglich der Motivation,
mit Closure wird dort über Closure dort gesprochen,
dass das Unsichtbare, was eigentlich beim Spaghetti Code und das Unverständliche,
was dort hier kritisiert wird,
dass wir das auch haben mit Multiple Objects,
nämlich veränderlichen Objekten.
Und deswegen ist Unveränderlichkeit etwas, was wir so wichtig brauchen.
Bei diesen Unfalländerlichkeiten geht es darum, sie ändern sich wieder,
es retzt Sicherheit, wollen wir erreichen.
Und Nebeneffektfreiheit, das nur unveränderliche Datenstrukturen erlaubt werden.
Sowas braucht man auch manchmal. Wir kommen gleich,
wir können ja gleich mal hinschielen, wo wir das schön herkennen.
Sie wissen, die Streamklasse von Java,
die ist nicht mehr veränderlich und die Fachwerte in Wamm,
die wollen wir auch nicht verändern.
Also solche Sachen braucht man manchmal
Hierfür ist das eine wichtig im Prinzip der Funktionalen,
funktionalen Programmierpraktik mal Unwanderlichkeit. Also das bedeutet,
wenn wir eine Variable, eine Datenstruktur erstellt haben,
das Name Variable, möchte ich gleich zurückrufen, war falsch.
Also eine Datenstruktur erstellt haben, kann sie nicht mehr geändert werden.
Ja, so und wenn wir also immer eine Operation haben,
die wir, die wir mit solchen Datenstrukturen machen wollen,
dann erzeugen wir jedes Mal
eine Kopie
Das Ganze ist, das bereits zur Folge, dass das Ganze
voneinander getrennt ist. Die Operation macht nicht mehr das,
was arbeitet nicht mit dem gleichen Ding, was der Input war.
Und damit haben wir diese Nebenwirkungsfreiheit, Wechselwirkungsfreiheit. Und die Verständlichkeit
ist dadurch viel besser. Das ist der eine Punkt,
dass nämlich klar, als wir, die Auswirkung ist immer
nur auf dieses Ergebnis und nicht auf das, was der Input war.
Und wir haben damit diese Srat-Sicherheit gegeben. Gleichzeitig ist die Gefahr,
dass Daten inkonsistent werden viel geringer,
weil wir keine Veränderungen zulassen und eben für die die diese
Nebenläufigkeit Deadlocks und kann nicht auftreten und Locking brauchen wir.
Deswegen nicht. Wir schauen uns das mal auf ein Beispiel an.
Wir haben ein Objekt, nehmen wir mal an,
das wäre für die Himmelsbeobachtung.
Das soll die reale Welt darstellen, ein Planeten. Der Planet,
der hat einen Namen und wir nehmen jetzt hier noch ein Datum dabei dazu,
sagt, dass er uns sagt, das Entdeckungsdatum.
Ja, hat das schon Galileo entdeckt oder ist das
eben gerade erst vor drei Jahren entdeckt worden?
Ja, und dann machen wir ganz normal in Ghetta,
der dieses Datum uns gibt.
Alles gut oder was
Tatsächlich ist das ein bisschen gefährlich, weil wir bekommen ja
hier wirklich Zugriff auf ein Objekt, was Desert Turnwert hier gibt.
Wir bekommen das Objekt zurück. Das heißt, wir bekommen mit
dem Ghetta etwas, was wir dann von außen verändern können.
Wir könnten dann das Entwicklungsdatum verändern, obwohl wir gar nichts
mit dem Objekt machen dürfen.
Das ist eigentlich brei wird. Die nächste Variante könnten wir sagen,
okay, wir haben schon mal gehört,
Final verhindert ja
die Veränderung
Tatsächlich können wir hier die Referenz nicht ändern. Ja,
also wir können nicht ein anderes Objekt hinschieben. Ja,
aber wir können durchaus den internen Wert von diesem Objekt,
den können wir durchaus ändern.
Daran sind wir nicht geändert. Also insofern haben wir hier
das Ziel erst mal nicht erreicht. Aber es gibt eine Möglichkeit,
dass der Unveränderlichkeit trotzdem zu erreichen, indem wir eine Kopie erzeugen.
Das heißt, hier Defensive Copy, also eine Defensive Variante,
das Kopieren, um etwas auszuschließen, um Änderungen zu verhängern.
Ja, wir geben also nicht die Differenz direkt zu,
sondern wir ergeben ein neues Objekt zu, was zurück,
was diese Zeit genommen hat und daraus ein Date-Objekt.
Das ist ein Konstruktor von Date, dass wir ein neues Date-Objekt erzeugt haben.
Und das ist genau, das kann jetzt,
wenn wir damit was das rausgeben und damit was ändern,
ändern wir das Ursprüngliche, was hier im Planeten steht, nicht.
Das ist diese Rückwirkungsfreiheit, die wir erreichen wollen.
Und das ist nebenbei, merkt auch das,
was wir mit Fachwerten ja machen sollen.
Wir haben in der Mediathek diesen Geldbetrag zum Beispiel da
immer mehr ja nichts
So, und wer kam noch eine andere Möglichkeit,
etwas zu machen? Nämlich eben, dem wir Collections benutzen,
dem wir Veränderungen nur etwas nur zulassen bei Modifikationen,
die also, wir haben eben zum Beispiel hier eine Liste,
also erstmal, worum geht es hier?
Ein Kunde hat mehrere Telefone und er hat die Liste und da kann er
die alle hinzufügen und man kann die irgendwie zurückgeben, rausgeben.
Und da kann er die Liste als Kopie der Liste
über eine Collection machen
Soweit erst mal, das war das eine Beispiel und
das nächste ist, wo Bibliotheken helfen können.
Ja, also diese Bibliothek im Utable List,
die kann uns helfen, hier so etwas auch zu machen,
indem wir hier die Telefone zu dieser Inue-Deal-List hinzufügen.
Und damit haben wir so ein ähnliches Beispiel bekommen. Ja,
soweit erst mal, und damit sind wir schon,
nähern wir uns schon dem Ende.
Java kann natürlich sowas machen
Also zum einen, Java bietet diese Reflection API. Reflection,
Reflektion, Selbstreflexion, das kennen Sie aus der Psychologie.
Ich denke über mich selbst nach. Ich erkenne selbst,
was ich so brauche, was ich so für einmal bin.
Und so ist das in Programmiersprachen in manchen auch möglich.
Und die Reflection API, die erlaubt den Zugriff auf das Programm
auf sich selbst. Und da kann man zum Beispiel sagen,
was bin ich denn für eine Klasse oder was habe ich
denn für Felder oder sowas. Das ist eine Möglichkeit,
damit kann man die Unveränderlichkeit tatsächlich auch umgehen,
indem man dann sich das geben lässt und dann was dran ändert.
Das kann man durchaus machen. Und dann kann man, ja.
So, damit ist die Frage, objektorientiert oder funktional.
Ich bin jetzt ohne irgendwelche genaueren Beispiele nur so ein bisschen,
sage, wozu braucht man funktionale Programmierung?
Was sind die Objekte? Ach ja, da sollen wir nicht vergessen.
Auch mal zu den Beispielen nochmal zu gucken, also wie
kein Unveränderlichkeit erreicht werden. Das war jetzt das Beispiel,
Und was wir eben hier erreicht haben. So,
und jetzt die Frage nochmal, ob ich sie überzeugen könnte,
das funktionaler Programmierstall manchmal sinnvoll ist und wann ist das sinnvoll?
Wir fangen mal damit an, dass wir sagen,
die reine Lehre, das eine gibt es nicht.
Das Objektorientierte hat seinen Vorteil, das Funktionale hat seinen Vorteil.
Am besten wäre es, wir würden es kombinieren.
Jedes Paradigma hat Stärken und Schwächen
Objektorientierung hat seine extreme Stärke darin,
dass es die reale Welt abbilden kann. Also Dinge,
die eine Struktur haben, die Teile miteinander zusammenhängen.
Sowas kann man mit Objektoren hier wunderschön darstellen.
Funktionale Programmierung wiederum ist gut dazu dargestellt, dazu geeignet,
um Prozesse darzustellen. Rechenprozesse, Datenverarbeitungsprozesse und eben Sachen,
auch die wir also in der realen Welt
nebenläufig sind,
hier auch nebenläufig sind
Und Dakot, der dabei entsteht, lässt sich halt sehr viel stärker komprimieren,
ob das immer gut für die Verständlichkeit ist,
wage ich mal zu verzweifeln, zu bezweifeln.
So, jetzt, Sie haben schon ein bisschen meinen Worten entnommen,
was ich Ihnen vorschlagen möchte, ist eine Kombination.
Und zwar, diese Kombination gibt es als Architekturstil,
Franktional Core Imperative Shell, das heißt, die innere,
der Kern der Veranwendung, der wirklich die Datenverarbeitung macht,
der wird funktional gehalten,
während der andere Teil
der Herr Ringsrum ist
Der, wo es um Interaktion mit der Benutzer geht,
das Dialogsystem, das interaktive System, die sollen und dürfen Seiteneffekt behaftet sein.
Ja, das wäre, das wäre jetzt der Vorschlag, den wir hier haben. Und das ist,
wie gesagt, auch ein Funktionalprogrammierst den Architekturstil, ja,
und da fand ich schon kurz soll dabei die Domänenlogik,
also alles, was einen zum Beispiel Geschäftsregeln ist,
was, das soll ja Seideneffekt frei und immer gelten,
das wird ja zum Beispiel funktional implementieren,
ja, und dann gibt es noch die veränderlichen Objekte,
die woanders liegen,
ja,
und damit haben wir
eine Trennung erreicht
So, und an dieser Trennung lässt sich gut erkennen,
wo wir Fehlerbehebung machen wollen. Ja, so,
das war soweit erstmal dieser Teil,
das war heute sehr viel kürzer als sonst,
hat damit bisher zur Folge,
dass wir erstmal die Motivation gemacht haben