Am Ende soll es dann um etwas Philosophisches gehen, Design-Patterns, Entwurfsmuster heißen die auf Deutsch, bei den Collections, Containern, Datenstrukturen.

Als letztes Mal schon gesehen, als letztes Semester schon gesehen, es gibt so grundsätzliche Prinzipien, die man verwendet, wie solche Datenstrukturen gebaut sind. Obendrein gibt es übliche Funktionen, die man hat.

Wie suche ich in so einer Datenstruktur, wir haben verschiedene Suchverfahren, Sortierverfahren. Eine Ebene höher sind diese Design-Patterns. Da geht es darum, wie baue ich Klassen auf vernünftige Weise. Gibt es Entwurfsmuster, Muster für den Entwurf von Software, die ich recyceln kann.

Also nicht ganz unten irgendwelche Warteschlangen oder Stacks und nicht welche Sortier-Algorithmen, sondern weiter oben. Gibt es große Bausteine, die ich weiter verwenden kann, wie Klassen zusammenspielen. Was ist Baustein an der Stelle falsch gesagt?

Nicht Baustein, gibt es Arten des Wechselspiels zwischen Klassen. Eine Sorte haben wir kennengelernt bei den Ereignissen. Das nennt sich das Observer-Pattern. Das ist das, was Sie schon gesehen haben im Seminar, beziehungsweise im Praktikum Observer-Pattern.

Mit den Ereignissen, Observer-Pattern. Die sind nicht nur in .NET so, die sind in Java so, die sind in den meisten Bibliotheken für C++ so. Mit diesem Pattern. Zu den Pattern gehören zwei Klassen, die zusammenspielen.

Ein Observable. Also ein etwas beobachtbares Observable und ein Beobachter.

Der Observer ist das Ding, was nachher eine Mitteilung kriegt. Der hat sozusagen diese Nachricht abonniert. Der wartet auf solche Nachrichten. Das ist der Observer.

Observable ist dasjenige, was die Nachrichten sendet. Das beobachtet werden kann. Was muss das Observable können? Es braucht eine Funktion zum Registrieren. Ein Observer muss sich anmelden können. Das haben wir gesehen bei den Ereignissen.

Ich mache das jetzt nicht auf. Bei den Ereignissen haben wir es gesehen beim Timer. Da gab es so etwas wie Timer.tick plus gleich. Mein Funktionsname. Dieses plus gleich ist das Registrieren. Ich registriere die Funktion bei dem Timer.

Der Timer wäre das Observable. Und die Funktion ist registriert. Also der braucht eine Registrierungsfunktion, wie auch immer die heißt. In dotnet heißt die typischerweise plus gleich. Ganz billig. Man braucht eine Funktion zum Deregistrieren. Dieses plus heißt öffentlich.

Deregistrieren sind voller Weise. Sollte ich mich auch abmelden können. In dotnet ist das einfach minus gleich. Nicht in dotnet. In C sharp ist das minus gleich. Deregistriere in der Form. Und der Observer braucht eine Methode, die dann eben aufgerufen wird vom Observable.

Zum Bescheid sagen. Das war bei uns jetzt sowas wie... Da haben wir es schon hier in dem Programmchen drinnen. Buttonklickt. Das wäre die Funktion, die aufgerufen wird.

Jetzt muss man gerade in mich gehen, wie ich die geschickt benenne. Nennen wir die Empfangen. Wie auch immer sie in den jeweiligen Systemen heißt. Also der Abonnent meldet sich an.

Beim Observable. Das wäre bei uns zum Beispiel ein Knopf. Oder die Listbox. Oder meldet sich ab. Oder wird von anderen angemeldet. Oder wird von anderen abgemeldet. Auf jeden Fall brauchen wir so eine Registrierungs- und Deregistrierungsfunktion. Und das Observable ruft dann eine Methode, heißt es dann später, eine Funktion von dem Observer auf.

Um Bescheid zu sagen. Daran besteht das Umbenommen. Das ist der Kern von diesem Observerpattern. Man könnte es vielleicht so noch einmal... Der Observer wird registriert.

Registriert. Und das Observable ruft den Observer auf. Sagt dann nachher Bescheid. Wenn etwas passiert ist. Das ist ein ganz billiges von diesen Pattern. Von der Sorte gibt es 20, 30, 40, 50, 100. Je nachdem wie man zählt. Aber einige sind elementar wichtig. Und kommen dir dann auch überall vorkommen.

Wie dieses hier. Das bei praktisch allen Systemen für grafische Oberflächen vorkommt. Das steht am Ende. Und ganz am Ende will ich dann noch einmal sagen, was denn eigentlich dort nett von innen ist. Dieses System auf dem das ganze basiert.

Sehr analog zu Java. Das haben wir im Visual Studio gesehen. Es gibt ja anscheinend mindestens vier Programmiersprachen. Die alle in .NET verwendet werden können.

Es gibt noch diverse weitere. Die sind dann nicht eingebaut. Also wir haben zumindest ab Werk C Sharp, Visual Basic und F Sharp und C++. Eine besondere Form von C++, aber sieht schon meist aus wie C++. Die verwendet werden können.

Der Compiler erzeugt nicht, wie wir es bei C hatten, direkt Maschinensprache. Sondern erzeugt etwas, das nennt sich EL bei Microsoft Intermediate Language. Eine Zwischensprache. Bei Java heißt es dann Bytecode. Diese Zwischensprache wird dann später tatsächlich kompiliert.

Und ausgeführt. Das muss man auch noch einmal diskutieren. Wann wird sie denn eigentlich kompiliert? Zu welchem Zeitpunkt? Das ist noch eine Nummer komplizierter. Und das ist im Zweifelsfall bei Java und bei .NET nicht dasselbe. Aber das Grundprinzip ist dasselbe.

Also es wird nicht direkt in Maschinensprache übersetzt. Es wird in so eine Zwischensprache übersetzt. Das hat zum Beispiel den positiven Effekt, dass viele Sachen lesbar bleiben. In dieser Zwischensprache lässt man insbesondere lesbar,

wie die ganzen Funktionen und Daten hießen. Das erspart uns die Header-Dateien, die Sie in C und C++ nicht gesehen haben, die Sie in C gesehen haben. Die Header-Dateien, mit denen ich erstmal sage, was sind denn überhaupt meine Daten, was sind meine Funktionen. Weil das Ganze in diesem Zwischenformat ist, kann der Compiler einfach selbst feststellen,

was sonst der C-Compiler aus den Header-Dateien haben müsste. Keine Header-Dateien mehr. Das macht das Ganze deutlich einfacher. Ich muss nicht mehr jede Funktion zweimal schreiben. Hier steht einfach Button1Click. Und ich brauche nicht noch eine Header-Datei,

in der ebenfalls Private-Vault Button1Click steht. Der Compiler sucht sich das selbst zusammen. Aus diesen Zwischen-Dateien. Und dem, was mit dranhängt, Metadaten. Das gucken wir uns ganz zum Schluss an.