Welches Paradigma passt zu Dir?

Im Internet werden ständig sinnlose und anstrengende Glaubenskriege geführt. Das fängt damit an, welches Betriebssystem besser ist und geht dann weiter, welcher Browser cooler ist.
Diese Diskussionen kennt sicher jeder zur Genüge.

Nun müsste man meinen, dass wir als Softwareentwickler innerhalb unseres Bereiches vernünftiger wären. Tja, schön wär's. Da gibt es fast noch hitzigere Debatten, welche Sprache oder welches Paradigma besser ist.
Auch diese Diskussionen werden eher subjektiv, als objektiv geführt.
Man hört aber immer öfter heraus, man solle die Sprachen und Paradigmen wie Werkzeuge betrachten. Und so soll man eben immer das Werkzeug auswählen, welches zu einer bestimmten Problemstellung passt.

Nun haben wir aber das große Glück, dass mittlerweile fast alle größeren bekannten Programmiersprachen Multiparadigmensprachen sind. Damit sollte sich die Wahl der "richtigen" Sprache beinahe erledigt haben. Oft liest man auch von den vernünftigeren Diskutanten, dass man die Sprache wählen soll, dessen Syntax einem besser gefällt. Soweit, so gut!

Und wie ist das mit den Paradigmen? Da bleiben noch viele stur und möchten anderen gerne ihr eigenes bevorzugtes Paradigma aufdrängen. Der große Vorreiter unserer Zeit ist wohl die OOP. "Denn alles andere ist ja out und von vorgestern!"
Und leider wird einem dieses Paradigma wirklich oft aufgezwungen. Da braucht man sich nur mal die Bibliotheken rund um .NET oder Java anzugucken. Da geht wirklich nix mehr ohne OOP.

Was ist aber, wenn man nicht immer objektorientiert denken kann bzw. will? Was ist, wenn einem dieses objektorientierte Zeug Komplexe bereitet oder gar Denkblockaden auslöst?

Das klingt absurd? Sowas ist Unsinn? Der Softwareentwickler ist einfach nur zu dumm für OOP?

Dann sind Linkshänder aus der Sicht eines Rechtshänders sicher auch nur zu dumm, um mit der rechten Hand zu schreiben. Sollen sie doch gefälligst lernen, mit der rechten Hand zu schreiben. Immerhin kann die Mehrheit der Menschen auch mit der rechten Hand schreiben.
Zum Glück wurde diese Einstellung aus den Köpfen der meisten Menschen verbannt. (Auch, wenn bis dahin viele Linkshänder zur Rechtshändigkeit gezwungen wurden. Ich wollte früher als Kind auch mit Links schreiben ... aber mit spiegelverkehrter Schrift. Ich sollte dann aber mit der rechten Hand schreiben ... was ich auch heute noch tue. Ob das meine geistige Entfaltung beeinträchtigt hat, kann ich nicht klar sagen. *g*)

Warum ist das aber noch nicht in den Köpfen der Softwareentwickler angekommen?
Paradigmen werden immer noch wie Werkzeuge behandelt, die nur für ein bestimmtes Problem in Frage kommen und bei anderen wiederum nicht in Frage kommen (dürfen!).

Gerade in der OOP wird mit Dogmen umher geworfen, wo man meinen könnte, man hat die zehn Gebote vor sich. Da gibt es dann sogar Kampagnen, wie z.B. die "Anti-If-Kampagne", wo ich in dem Moment nicht weiß, ob ich lachen oder weinen soll. Früher war das böse "goto" das Übel allen Übels und musste bekämpft werden. Oh, das hat man auch erfolgreich durchgesetzt! Oder traut sich heute noch jemand ein wohl überlegtes "goto" in seinen Quellcode zu setzen, wenn es dem besseren Verständnis oder gar der Performance dient? Das macht kaum noch jemand, weil viele Angst haben, als unfähig bezeichnet zu werden.
Und nun versucht man das Selbe mit dem "if-then-else"-Konstrukt. Denn es gibt ja dafür die heilige Polymorphie. Und wer die nicht in seinem Programm verwendet, ist doch von vorgestern und unfähig.

Aber ich schweife etwas ab.

Der Punkt ist aber, dass man offenbar versucht, ein bestimmtes Paradigma zu DEM global gültigen Paradigma zu erheben. Dabei fragt aber keiner, ob man damit überhaupt zurecht kommt, oder nicht. (Gibt es überhaupt noch Frameworks, die nicht objektorientiert aufgebaut sind? Das ist eine ernsthafte Frage. Mir fällt da höchstens spontan die normale Win32-API ein.)

Dazu möchte ich ein Zitat einstellen, was mir sehr gut gefallen und mich dazu veranlasst hat, diesen Beitrag zu schreiben. Es ist auf der Seite "OOP Criticism" unter der Überschrift "One Mind Fits All?" zu finden:

...I was always told that OO was an intuitive way of thinking. Although I develop daily in OO languages, I do find OO rather unintuitive (although I manage). ... If I analyze a problem, I draw tables not objects and classes, I think in tables, those are much more intuitive to me. Even when I program in OOP, I rely as much as possible on tables. ...it's nice to see that I'm not the only one who 'thinks' in tables. ...

Es geht doch am Ende genau darum: Welches Paradigma passt zu Dir?
Einer denkt in Bildern, ein anderer in Tabellen und wieder ein anderer denkt in Wörtern oder etwas ganz Anderes.

Vielleicht sollten wir in Zukunft diesbezüglich offener und toleranter sein.
Es gibt eben nicht DAS Paradigma. Es gibt auch nicht DAS Paradigma für ein bestimmtes Problem.
Es kann nur DAS Paradigma geben, was DU in einem bestimmten Kontext für richtig hältst und womit DU am Besten zurecht kommst.

Wenn man in diesem Punkt die Freiheiten lässt, kann auch eine Entwicklung statt finden. Zum Einen kann man sich persönlich entwickeln, wenn man sein passendes Paradigma sucht. Zum Anderen kann man aber auch die Softwareentwicklung aktiv verändern. (Vielleicht entstehen dadurch sogar noch ganz andere Paradigmen?!)

Softwareentwicklung ist ein kreativer Prozess! Und Kreativität muss sich frei entfalten können! :-)

Warum versucht man die Welt zu modellieren?

Inspiriert durch den letzten Beitrag von Ralf Westphal "Mehr vom Selben hilft nicht mehr", dachte ich mir, dass es durchaus sinnvoll sein kann, der Kernaussage noch mehr Ausdruck zu verleihen. Ganz im Sinne von "Spread the word!"

Längere Zeit vorher beschäftigte ich mich auch mal mit Konzepten, wie z.B. Funktionale Programmierung und Data Oriented Design.
Und ich sagte so zu mir: "Verdammt! Recht haben sie!"

Es geht seit der Erfindung des ersten Computers um Datenverarbeitung. Und das möglichst effizient und seiteneffektfrei!

Warum ist das aber in Vergessenheit geraten? Haben wir schon lange den Boden unter den Füßen verloren?
Das kann man wohl annehmen. Dank *hust* der Objektorientierten Programmierung (OOP) programmiert man nicht mehr, sondern modelliert nur noch. Es wird alles Erdenkliche in Klassen beschrieben und durch Objekte ins Leben gerufen. Ob das nun sinnvoll ist, oder nicht. Egal! "OOP ist ja sooo geil und überhaupt kann man damit viel besser die Welt beschreiben."
Ja, man kann damit wunderbar die Welt beschreiben und modellieren. Damit wirbt zumindest jedes mir bekannte OOP-Buch.
Gerade, um den Leser für Vererbung zu begeistern, werden wirklich immer diese trivialen Beispiele, wie z.B. die Tierklassen, Autoklassen, Baumklassen, etc. aufgeführt.
Aber ganz ehrlich: Derartigen trivialen Nonsens habe ich bisher noch nie in meinen Softwareprojekten vorgefunden. In der Software-Realität gibt es eher "Tierautos mit Blättern dran". Das liegt ganz einfach daran, dass man viele Dinge im Businessproblem nicht so einfach klassifizieren kann, wie es einen die OOP-Autoren gerne schmackhaft machen wollen. Objekte müssen miteinander interagieren und Daten austauschen, denn nur darum geht es letztlich wieder: um die Datenverarbeitung.

Aber auch dafür hat sich die OOP-Gemeinde einige Konstrukte ausgedacht, die sich Entwurfsmuster "schimpfen". Überhaupt wurde der Trend eingeleitet, man solle nicht mehr "ableiten" und "vererben", sondern "komponieren". Dies sei flexibler, sagt man. (Was ich auch nicht bestreiten will.)

Doch sehe ich die Entwurfsmuster eher als Krücke. Nach dem Motto: Not macht erfinderisch.
Und, dass diese Entwurfsmuster nur ein Notnagel sein können, sieht man z.B. am "Visitor Pattern" oder dem "State Pattern". Die mögen ja wunderbar funktionieren, aber den Quellcode darf man hinterher nicht verstehen, geschweige denn debuggen wollen.

Tja, das hat alles nicht mehr den Eindruck, als wolle man Daten verarbeiten, sondern als wolle man geschickt mit einem Netzwerk aus Objekten um die Daten herumtanzen, ohne diese direkt zu berühren.

Es denkt doch keiner mehr an den Prozessor und an den Speicher.

Die OOP widerspricht immer noch der Arbeitsweise der gegenwärtigen Rechner. Denn im Rechner sind noch immer die Daten vom Code getrennt. Der Prozessor kennt keine Klassen, Objekte und erst recht keine Entwurfsmuster. Das wäre ja alles kein Problem, wenn die Zugriffszeiten auf den Arbeitsspeicher nicht den Prozessor unnötig ausbremsen würden.

Ganz ehrlich: Ich würde kein Prozessor sein wollen, der ein OO Programm bewältigen muss. ;-)

Warum versucht man also die Welt - das Businessproblem - in ein OO-Schema zu pressen, welches der Compiler wieder halbwegs entfrickeln (Code von Daten trennen) muss, damit es der Prozessor dann mehr schlecht als optimal lösen "darf"?

Und wie man dem Beitrag von Ralf entnehmen kann, geben die OOP-Gurus zu verstehen, dass die Mehrheit nach so vielen Jahren noch immer nicht richtig OO programmieren kann.

Ja, da muss man wirklich fragen, wessen Problem das ist? Ich brauche diese "Religion" OOP nicht wirklich, um meine Business-Probleme auf Arbeit zu lösen. Das habe ich jedoch leider eher spät gemerkt, weil ich auch auf den OOP-Zug aufgesprungen bin, der sehr gut beworben wurde. Hinterher fand ich die Codebasis aber trotzdem nicht schön. Vielmehr war alles so aufgeblasen und ich verlor den Überblick.

Ich frage mich aber wirklich, warum die OOP-Gurus so hartnäckig an der Objektorientierung festhalten. Geht es dabei nur um das Modellieren der Welt?
Wäre es nicht sinnvoller, ein Paradigma zu wählen, welches dem Programmierer gleichermaßen entgegen kommt, wie der Hardware? Wenn man nicht mehr versuchen würde, die Business-Probleme 1:1 mit Objekten zu beschreiben, sondern die Probleme grundlegend abstrahieren würde, sodass diese einfacher zu fassen und für die Hardware optimal beherrschbar sind?

Vielleicht hat man damals die Idee - den Code von den Daten getrennt zu halten - zu schnell verworfen. Denn gerade die Rechnerarchitektur zeigt uns doch, wie die Daten am besten verarbeitet werden können. Und solange sich die Architektur nicht ändert, ist es IMHO keine gute Idee, weiterhin die Daten mit dem Code zu mischen.

Ich bin zumindest gespannt, wohin die Reise gehen wird. Spätestens mit den ersten Quantenrechnern dürfte sich noch so Einiges ändern. ;-)

Ansichten ändern sich!

Es ist nun schon eine Weile her, als ich hier einen Beitrag geschrieben hatte. Ich nutzte die Zeit, um mit der MPT ein wenig Erfahrung zu sammeln. Dies tat ich mit einem Projekt auf Arbeit.

Naja, es funktionierte schon alles so, wie ich mir das gedacht hatte. Jedes Objekt war im Grunde unabhängig voneinander und der Datenfluss geschah eher passiv. Eigentlich genau das, was ich wollte, oder?
Nun ja, nicht ganz.
So bereitete mir z.B. die Idee des Transmitters in einem Anwendungsfall ziemliche Probleme:
Nehmen wir an Objekt A ist ein Transmitter für irgendeinen Wert X.
Objekt B und Objekt C empfangen diesen Wert X.
Objekt B fordert den Wert X an. Diesen Wert bekommt Objekt B von Objekt A. Aber auch Objekt C bekommt diesen Wert X, weil es ja ebenfalls als Empfänger für diesen Wert registriert ist.

Das scheint soweit OK zu sein, oder? In meinem Fall war dies aber nicht gewollt, weil das unaufgeforderte Empfangen des Wertes X eine Ereigniskette ausgelöst hat, die nicht hätte ausgelöst werden dürfen.
Also, wenn Objekt A den Wert X anfordert, darf ihn nicht Objekt B bekommen. Und wenn Objekt B den Wert X anfordert, darf ihn nicht Objekt A bekommen.
Das ist ein ziemliches Dilemma, welches einen schon mal verzweifeln lässt.
Meine erste Idee war es ja, bei den Objekten A und B eine Flag-Variable einzuführen, welche in der Empfangsroutine prüft, ob der Wert X überhaupt angefordert wurde.
Doch das schlug ich mir schnell wieder aus den Kopf, denn so eine "Prüfung" verschmutzt die Businesslogik. Zudem wissen die Objekte gar nicht, was um sie herum geschieht. Diese Flag-Variable würde aber indirekt andeuten, dass dieses Objekt etwas über seine Umgebung weiß. Und das wäre schlecht!

Ich überlegte lange, wie ich das Problem lösen könnte. Dann kam mir die Idee! Man könnte ja einfach ein Objekt dazwischen schalten, welches wie ein Ventil funktioniert. Man schaltet es z.B. einfach zwischen Objekt A und Objekt B. Die Anforderung von Objekt B geht durch das "Ventil". Dabei wird in dem "Ventil" ein Flag gesetzt, welches den Empfang von Wert X erlaubt. Es ist somit "offen". Wenn dann der Wert kommt, wird der Wert an Objekt B durchgereicht und das Ventil wird wieder geschlossen. Bei einem unaufgeforderten Empfang wird der Wert einfach abgewiesen und Objekt B bekommt davon gar nix mit.

Nachdem ich das so eingebaut hatte, funktionierte alles wieder problemlos. Die Ventile sorgten für den gewünschten Datenfluss und die Businesslogik hatte sich absolut nicht geändert. Genial!

Unzufrieden, trotz entkoppelter Objekte
Die Anwendung funktionierte, aber mir war unwohl bei dem Gedanke, dass noch mehr Funktionen in die Software fließen sollten.
Wie kann das sein? Die Entkopplung sollte ja eigentlich das Gegenteil bewirken und Sicherheit bei der Implementation neuer Funktionen erzeugen. Ein Grund für die Unsicherheit war wohl auch das oben geschilderte Szenario.
Viel schlimmer war aber gerade die totale Isolierung der einzelnen Businessobjekte zueinander. Das heißt, ich konnte aus einem Objekt heraus nicht die Kommunikationsstrecke verfolgen.
Wollte ich also wissen, was passiert, wenn ich auf einen bestimmten Button klicke, so kam ich zwar zur entsprechenden Aufrufmethode, doch dann war da eine Sackgasse. Der Isolation sei "Dank", stand da in den jeweiligen Methoden nur die Floskel "Say.Carefully(MacheIrgendwasSinnvolles, this)".
"Ach ja, toll! Und welches Objekt ist jetzt nochmal dafür zuständig, diese Sache auszuführen?" fragte ich mich des öfteren.
Denn leider steht man hier wirklich in der Sackgasse. Man kann nicht einfach zur Definition von "MacheIrgendwasSinnvolles" springen, um den Programmfluss nachzuvollziehen. Das ist der Preis, den man für die Isolation bezahlt. Und der ist teuer!
Um also zu wissen, welches Objekt auf dieses Ereignis reagiert, muss man sich die Verdrahtung angucken. Gut, jetzt hat man das verantwortliche Objekt lokalisiert. Man geht in die Klasse und sucht sich die entsprechende Methode. Die Freude hält nicht lange an, denn in der Methode steht auf einmal der Aufruf "Say.Carefully(INeedEinenBestimmtenWert, this)". "OMG!"
Aber zum Glück ist es an der Stelle tatsächlich nicht wichtig, wo der Wert herkommt. Ich suche in der Klasse schnell die passende Receive-Methode und fahre mit der Programmverfolgung fort. In der Receive-Methode wird Business-Logik ausgeführt. Ein neuer Wert wird darin berechnet. (Um Missverständnissen vorzubeugen: Diese Werte sind natürlich auch Objekte. Es sind aber eben spezielle Value-Objekte und keine primitiven Datentypen! Ich bin auch dabei, mir abzugewöhnen, primitive Datentypen direkt zu transportieren, weil diese einfach nichts aussagen und zudem nicht erweiterbar sind.)
Weiter geht's: Am Ende dieser Methode steht dann also wieder "Say.Carefully(SendNeuerWert, this)".
Jetzt geht das Geeier wieder los. "Wer nimmt den Wert entgegen und was passiert damit?". Also wieder zurück und von "oben" drauf gucken, weil ja das Objekt für sich isoliert gewesen ist.
So geht das dann immer weiter. Besonders "lustig" wird es dann, wenn man wirklich einen Bug lokalisieren muss und die Zeit drängt. Da springt man hin und her ... hoch und runter. Wenn man Glück hat, findet man den Bug.

Eine gewisse Ordnung, und trotzdem Chaos
Alles hat im Grunde eine ordentliche Struktur, aber für mich ergibt sich ein Gefühl von Chaos, dass ich auf Dauer nicht zu bändigen vermag. Ursache dessen ist gerade diese Isolation der Objekte! Aus einem Objekt heraus kann ich nicht einfach auf den Programmfluss schließen. Und weil die Objekte äußerlich von nix abhängig sind (fehlende Konstruktorargumente), weiß ich ja nicht mal, ob diese Objekte überhaupt benötigt werden. Ist ein bestimmtes Objekt für einen bestimmten Vorgang unerlässlich? Vielleicht ja? Vielleicht nein? Welche Events von dem Objekt müssen verdrahtet werden, damit die Software funktioniert? Welche davon sind optional?
All das sagt das Objekt, von außen betrachtet, nicht aus.
Ich sehe mir bei einem Softwareprojekt nicht zuerst an, wie die Objekte verdrahtet sind. Der naive Ansatz, den ich immer verfolge, wenn ich wieder mal wissen will, wie etwas funktioniert, ist Folgender:

Im Grunde haben alle meine Anwendungen ein quasi statisches Hauptformular. Dieses nehme ich mir her und im Entwurfsfenster sehe ich es dann mit all seinen Buttons usw. Wenn ich wissen will, welche Funktion sich hinter einem Button verbirgt, klicke ich doppelt drauf und springe in die entsprechende Routine. Bei der MPT beginnt dann jenes Szenario, welches ich oben dargestellt hatte.
Und DAS macht keinen Spaß! Das Formular ist zwar dadurch wunderbar entkoppelt, aber für sich gesehen ist es absolut sinnlos, weil es nix über die Funktionalität der Software aussagt. Nun kann man sich darüber streiten, ob man so beginnen sollte, eine Software zu lesen. Aber, hey! Eine User-Story beginnt schließlich so: "Wenn ich auf den Button klicke, dann ...!" Und dann beginnt die Business-Logik zu fließen. Aber bei der MPT fließt erstmal nix, sondern man kommt gerade an dieser Stelle zum Stillstand, wo es interessant wird. In meinen früheren Projekten ist an der Stelle tatsächlich die Story geflossen. (Auch wenn da in der Anfängerphase(!) eine furchtbare Struktur zum Vorschein kam und die Domänen häufig gemischt waren, wirkte diese weit weniger chaotisch, als die MPT! Denn man konnte wenigstens hintereinander weg dem Programmfluss folgen! Und das ist absolut wichtig, wenn man Software verstehen will!)

Zurück zu den Wurzeln
Eine totale(!) Entkopplung, also Isolation von Objekten, mag ja auch ihre Vorteile haben. Aber mir hat sie in der Praxis das Verstehen meiner eigenen Software nur erschwert. Denn wie gesagt: Ich gucke in erster Linie nicht auf den "Schaltplan", also danach, wie die Objekte miteinander verknüpft sind. Man hat schließlich immer noch Quellcode vor sich, den man wie eine Geschichte lesen können soll.
Das geht aber NICHT, wenn man hier nur isolierte Klassen vor sich hat.
So konnte das nicht weiter gehen! Immer dieses "von Sackgasse zu Sackgasse" springen machte absolut keinen Spaß!
Was würde also dagegen sprechen, Objekten wieder die gewohnte Abhängigkeit zu verleihen? Sie also miteinander lose(!) zu koppeln? Nix würde dagegen sprechen! Die lose Kopplung würde einen aber wieder zu einem lesbaren Programm verhelfen! Und das ist mir wichtiger, als auf biegen und brechen meine Klassen total zu entkoppeln. Das nützt mir nix, wenn ich die Software am Ende nicht vernünftig lesen kann. Schlimmer noch, wenn sich der Lesefluss so anfühlt, als ob ich von einer "goto-Anweisung" zur nächsten "goto-Anweisung" springe. Man nennt das "Spaghetti-Code". Genauso fühlt sich aber auch das Nachvollziehen des MPT-Codes an!

Dependency Injection neu entdeckt: DIY-DI
Dependency Injection (DI) ist mir nicht unbekannt. Durch Misko Hevery, einem regelrechten DI Enthusiasten, hatte ich die Thematik so richtig vertieft. Warum hatte ich aber das Prinzip der DI nicht weiter verfolgt? Im Grunde hatte mich die manuelle Objekterzeugung abgeschreckt. Sowas kann dann schon mal unübersichtlich und komplex werden. Natürlich gibt es auch DI-Frameworks, welche einem die Arbeit abnehmen sollen.
Wenn ich aber eines hasse, dann sind es irgendwelche Frameworks, von denen man sich wieder abhängig macht. Frameworks, wo im Hintergrund irgendwas "Magisches" passiert, kann ich nicht leiden. Ich möchte in meinem Quellcode jede Kleinigkeit nachvollziehen können. Dass ich da beim .Net-Framework mit einem relativ hohen Abstraktionsgrad leben muss, ist mir da schon genug "Magie". Da brauche ich nicht noch irgendein mysteriöses Framework, wo ich nicht weiß, was da im Detail passiert.

Nun bin ich da aber vor kurzem bei Misko Heverys Blog auf einen Artikel gestoßen, der in mir wieder das Interesse für DI geweckt hat: Do it Yourself – Dependency Injection (DIY-DI). (Der eigentliche "Erfinder" dieser Idee ist aber Chad Parry und sein originaler Beitrag befindet sich dort.)
Als ich mir die Präsentation und das PDF dazu durchgelesen hatte, war mir schlagartig klar, dass ich meine Software zukünftig SO und nicht anders entwickeln möchte! Das ist genau das, was ich unter sauberen Quellcode verstehe.
DI ist im objektorientierten Bereich nun mal ein probates Mittel, um Ordnung in seine Struktur zu bekommen. Wenn ein Objekt auf andere Objekte angewiesen ist, damit es funktionieren kann, sollte es dies doch äußerlich kenntlich machen. Das gibt eine gewisse Transparenz und zugleich eine enorme Sicherheit für den Programmierer. Man sieht sofort, mit welchen Objekten das Zielobjekt unmittelbar interagiert und man weiß, dass das Objekt voll funktionsfähig ist, wenn es die geforderten Objekte injiziert bekommt. (Zumindest sollte das so sein. Stichwort: "Law of Demeter")

So habe ich auf Arbeit damit begonnen, mein derzeitiges Projekt nach DIY-DI zu migrieren. Und mir bereitet es erstmals wieder Freude, Funktionalität hinzuzufügen.
So begann meine Überlegung: "Das Business-Model benötigt kein User Interface, um zu funktionieren. Aber ein User Interface benötigt ein Business-Model, um zu funktionieren."
Das erscheint auch logisch. Spinnt man das noch eine Ebene weiter, so benötige ich als Benutzer das User Interface, um die Software bedienen zu können! Das ist Fakt!
Ich, als Mensch, bin ja auch nicht isoliert von meiner Umwelt. Die Umwelt ist zwar nicht abhängig von mir, aber ich von ihr. So brauche ich z.B. die Luft zum Atmen, usw.

Um zur Software zurück zu kommen, injizierte ich also einen "MainPresenter" in meine "MainForm". Und über den "MainPresenter" fordere ich nur die Dinge an, die für das User Interface von Belang sind. Der "MainPresenter" ist von diversen Service-Objekten abhängig, die er benötigt, um die Anforderungen vom User Interface erfüllen zu können.
So hatte ich schon einige Funktionalitäten von der MPT-Architektur umgestellt. Alles ist auf einmal so einfach nachvollziehbar geworden. Der Aufruf, "Gehe zu Definition" in Visual Studio, ist mir endlich wieder von Nutzen, weil ich mit dessen Hilfe wirklich hintereinander weg die komplette Aufrufhierarchie nachvollziehen kann.

Das soll es erstmal soweit gewesen sein. Die totale Entkopplung ist für mich einfach nicht mehr attraktiv.

Mittelmänner bleiben, wie sie sind!

In meinem letzten Beitrag war ich ja völlig begeistert von der Idee, die Infrastruktur der Asynchronisation und Synchronisation in die Mittelmänner zu verschieben.

Davor will ich aber an dieser Stelle ausdrücklich abraten!

Ralf Westphal hatte mich davor gewarnt, die "Vermittler" mit mehr Aufgaben zu beladen, als sie eigentlich tun sollten. Und da hat er absolut Recht!

Warum habe ich aber mit meiner Grundidee gebrochen und die Vermittler mit der Synch/Asynch-Angelegenheit belastet?
Ganz einfach: Ich hatte einen Denkfehler. *g*

Ich hatte einfach zu kompliziert gedacht. Das möchte ich mal genauer erklären:
Mein Gedanke ging in die Richtung, wie es auf dem folgenden Bild dargestellt ist.

Für den Asynch/Synch Aspekt werden eigene Mittelmänner und Schnittstellen definiert. (Zum Vergrößern auf Bild klicken.)

Meine Idee war es, für die Asynchronisation und Synchronisation auch entsprechend eigene Mittelmänner und Schnittstellen zu definieren. Das erschien mir aber viel zu unflexibel und zu aufwändig, weshalb ich mich für den unschönen Hack entschied, die Mittelmänner zu modifizieren. Zudem sah ich hierin schon fast das Todesurteil meiner MPT. Denn wenn ich mit der MPT nicht ebenso einfach solche flexiblen Konstrukte realisieren kann, wie es Ralf mit seinen EBCs dort gezeigt hat, so wäre die MPT schlicht unbrauchbar.

Und ich war wirklich schon nahe dran, die MPT zu vergessen und mich den EBCs zuzuwenden.

Nun, ich weiß nicht, warum ich erst letzten Freitag beim Autofahren auf die entscheidende Idee gekommen bin, welche die MPT ebenso flexibel macht, wie die EBCs. Dabei ist es im Nachhinein betrachtet schon fast peinlich, dass ich so umständlich gedacht habe.

Die Lösung zum Problem zeigt die folgende Grafik:

Hier werden einfach die bestehenden Mittelmänner und Schnittstellen verwendet. (Zum Vergrößern auf Bild klicken.)

Anstatt für die Asynch/Synch Aspekte eigene Mittelmänner und Schnittstellen zu implementieren, kann ich doch auch einfach die bestehenden Konstrukte verwenden. Denn die Asynch/Synch Modelle benötigen doch gar keine andere Signatur. Das heißt, es sind ja keine Adapter bzw. Translator, welche z.B. einen Text aufnehmen und eine Zahl zurückgeben. Oder die ein Trigger-Event aufnehmen und verschiedene konkrete Events auslösen.
Das war von Anfang an mein Denkfehler dabei.
Die Asynch/Synch Modelle sind doch in dem Falle einfach nur "Repeater". Sie können doch gleichzeitig der "Caller und Listener" oder "Transmitter und Receiver" sein. Das verbietet niemand.
Und das beste hierbei ist eben wieder der Vorteil der konkreten Trennung der Objekte. Die "MainForm" und das "BerechneModel" wissen nix von einer asynchronen oder synchronen Verarbeitung. Für sie ist alles so, wie immer. Und das ist ja auch der Sinn und Zweck bei der MPT (und auch bei Ralfs EBCs)! Man soll die Infrastruktur der Anwendung verändern können, OHNE die bestehende Business-Logik auch nur minimal zu verändern.
Was mir bei dem zweiten Bild besonders gefällt, ist die kettenartige Struktur, die man dadurch erhält. Man könnte hier sogar beliebig viele Zwischenglieder einfügen, denn der Input und Output ist für die Endknoten immer der Selbe!
Die Asynchronisaton und Synchronisation spielt sich nur in den jeweiligen Modellen und nirgendwo anders ab!
Und DAS ist wirklich genial! ;-)
(Heute hatte ich das auf Arbeit auch gleich in meinem Projekt umgeändert. Und es funktionierte anstandslos.)

Wie sieht nun der Quellcode dazu aus? Ich freue mich, sagen zu können, dass es fast so aussieht, wie bei Ralfs Asynch/Synch-Beispiel! :-)

So wird das zusammengesteckt:

using System;
using System.Collections.Generic;
using System.Windows.Forms;

namespace NewAsyncTest
{
 static class Program
 {
  /// <summary>
  /// Der Haupteinstiegspunkt für die Anwendung.
  /// </summary>
  [STAThread]
  static void Main()
  {
   Application.EnableVisualStyles();
   Application.SetCompatibleTextRenderingDefault(false);

   Form1 form1 = new Form1();
   BerechneModel berechneModel = new BerechneModel();
   Asynchronizer asynchronizer = new Asynchronizer();
   Synchronizer synchronizer = new Synchronizer();

   new BerechneMediator(
    form1,
    asynchronizer);

   new BerechneMediator(
    asynchronizer,
    berechneModel);

   new ErgebnisFrequency(
    berechneModel,
    synchronizer);

   new ErgebnisFrequency(
    synchronizer,
    form1);

   Application.Run(form1);
  }
 }
}

So sieht der Asynchronizer aus:

using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;

namespace NewAsyncTest
{
 public class Asynchronizer :
  IAmBerechneListener,
  IAmBerechneCaller
 {
  public void DoBerechne()
  {
   ThreadPool.QueueUserWorkItem(
    delegate
    {
     Say.Carefully(Berechne, this);
    });
  }

  public event EventHandler Berechne;
 }
}

So sieht der Synchronizer aus:

using System;
using System.Collections.Generic;
using System.Text;
using System.ComponentModel;
using System.Threading;

namespace NewAsyncTest
{
 public class Synchronizer :
  IAmErgebnisReceiver,
  IAmErgebnisTransmitter
 {
  private AsyncOperation asyncOp = AsyncOperationManager.CreateOperation(null);

  int ergebnis;
  public void ReceiveErgebnis(int ergebnis)
  {
   asyncOp.Post(new SendOrPostCallback(
    delegate
    {
     this.ergebnis = ergebnis;
     Say.Carefully(SendErgebnis, this);
    }), null);
  }

  public event EventHandler SendErgebnis;

  public int ReturnErgebnis()
  {
   return ergebnis;
  }
 }
}

Ein entsprechendes RAR-Archiv, mit dem Beispielprogramm, kann man sich auch wieder herunterladen: KLICK

Tja, keine Ahnung, aber beim Autofahren kamen mir bisher immer die besten Einfälle. *g*

Ich werde wohl im nächsten Beitrag mal die MPT mit den EBCs vergleichen. (Wobei ich die EBCs nicht als "Konkurrenz" betrachte. Das erkläre ich aber, wenn es soweit ist.)

Die Mittelmänner entwickeln sich!

Ich bin ja so glücklich über das, was ich heute erreicht habe! Aber schön der Reihe nach:

Die Mittelmänner entwickeln sich weiter!

Wie kann man das verstehen? Ganz einfach: Weißt Du noch, als ich in meinen Präsentationen (z.B. diese hier) gesagt habe, dass die Mittelmänner selber von Außen keine Zugriffsmöglichkeiten haben (sollen)?
Ich habe heute meine Meinung geändert! (Ich habe aber auch nie gesagt, dass die Micro-Pattern-Trilogie bereits vollendet ist.) ^_^

Ich bin bei Ralf Westphals Blog über diesen Beitrag gestolpert: Asynchrone Kommunikation mit EBCs statt “Async-Pattern”

Ralf hat da absolut Recht, wenn er sagt, dass die Dinge, wie z.B. Threads, nix in der Businesslogik zu suchen haben! Ich hatte aber auch am Anfang den Fehler gemacht, als ich mal diesbezüglich experimentiert hatte. Ich hatte aber auch keine Idee, wie ich es denn am besten anders anstellen könnte.

Und heute grübelte ich etwas über diesen Fakt nach. Die natürliche Trennung zwischen den Objekten stellen ja die Mittelmänner dar. Also ist es doch naheliegend, wenn man an diesem Connector festlegt, ob der Nachrichtenfluss asynchron oder synchron verlaufen soll und nicht in den Businessmodellen!

Guter Stil ist es ja, wenn man ein Framework so entwirft, wie man es später auch auf einfache Weise verwenden möchte. So kam ich auf folgende Idee:

using System;
using System.Collections.Generic;
using System.Windows.Forms;

namespace NewAsyncTest
{
 static class Program
 {
  /// <summary>
  /// Der Haupteinstiegspunkt für die Anwendung.
  /// </summary>
  [STAThread]
  static void Main()
  {
   Application.EnableVisualStyles();
   Application.SetCompatibleTextRenderingDefault(false);

   Form1 form1 = new Form1();
   BerechneModel berechneModel = new BerechneModel();

   new BerechneMediator(
    form1,
    berechneModel).Asynchronize();

   new ErgebnisFrequency(
    berechneModel,
    form1).Synchronize();

   Application.Run(form1);
  }
 }
}

Hier nochmal die relevante Stelle:

new BerechneMediator(
 form1,
 berechneModel).Asynchronize();

new ErgebnisFrequency(
 berechneModel,
 form1).Synchronize();

Wie man sieht, haben die Mittelmänner nun doch noch öffentliche Methoden bekommen.
Die "form1" ist der Auslöser für den "berechne"-Vorgang. Das "berechneModel" führt die Berechnung durch. Je nachdem, wie umfangreich die Berechnung ist, kann dies eine gewisse Zeit dauern. Deshalb wollen wir diesen Vorgang asynchron durchführen. Das hat zur Folge, dass der Nutzer in der Zwischenzeit ungehindert weiter mit der Anwendung arbeiten kann.

Wenn das "berechneModel" fertig ist, wird das Ergebnis einfach an die Form zurück gesendet. Aber Vorsicht! Es muss synchronisiert werden, weil die "form1" ein GUI ist. Tut man dies nicht, wird eine Exception geworfen!
Mit dem Methodenaufruf "Synchronize" ist das Thema aber schon gegessen.
So einfach kann die asynchrone/synchrone Nachrichtenverarbeitung sein. Und übersichtlich ist das ganze auch noch.
Ist das geil, oder ist das geil? ^_^

Und wie sieht die Sache intern aus?
Der Übersichtlichkeit halber, zeige ich hier nur mal den "BerechneMediator":

using System;
using System.Collections.Generic;
using System.Text;

namespace NewAsyncTest
{
 public interface IAmBerechneCaller
 {
  event EventHandler Berechne;
 }

 public interface IAmBerechneListener
 {
  void Berechne();
 }

 public class BerechneMediator : Middleman
 {
  private readonly IAmBerechneCaller caller;
  private readonly IAmBerechneListener listener;

  public BerechneMediator(
   IAmBerechneCaller caller,
   IAmBerechneListener listener)
  {
   this.caller = caller;
   this.listener = listener;

   this.caller.Berechne += Do(caller_Berechne);
  }

  void caller_Berechne(object sender, EventArgs e)
  {
   listener.Berechne();
  }
 }
}

Kein Witz! So sieht das wirklich aus. Mein Ziel war es ja, dass ich meine Pattern genauso weiterverwenden kann, wie ich es bisher getan habe.
Man sieht erst auf den zweiten Blick, was sich geändert hat. JEDER Mittelmann muss ab sofort von der abstrakten Klasse "Middleman" erben, wenn er die komfortablen synch/asynch Features nutzen will.
Wenn er diese geerbt hat, muss er beim Zuweisen des Event-Handlers die geschützte "Do"-Methode verwenden. Mehr ist hierbei absolut nicht zu tun.

Sehen wir uns nun die abstrakte Basisklasse "Middleman" an. Denn nur dort befindet sich die gesamte Infrastruktur.

using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;
using System.ComponentModel;

namespace NewAsyncTest
{
 public abstract class Middleman
 {
  private bool isAsynchronizer = false;
  private bool isSynchronizer = false;
  private AsyncOperation asyncOp = AsyncOperationManager.CreateOperation(null);

  public void Asynchronize()
  {
   isSynchronizer = false;
   isAsynchronizer = true;
  }

  public void Synchronize()
  {
   isSynchronizer = true;
   isAsynchronizer = false;
  }

  public void NormalMode()
  {
   isSynchronizer = false;
   isAsynchronizer = false;
  }

  protected EventHandler Do(EventHandler customMethod)
  {
   return new EventHandler(
    delegate
    {
     if (isAsynchronizer)
     {
      ThreadPool.QueueUserWorkItem(delegate { customMethod(this, EventArgs.Empty); });
     }
     else if (isSynchronizer)
     {
      asyncOp.Post(new SendOrPostCallback(
       delegate
       {
        customMethod(this, EventArgs.Empty);
       }), null);
     }
     else
     {
      customMethod(this, EventArgs.Empty);
     }
    });
  }
 }
}

Sieht kompliziert aus, ist es aber gar nicht. ;-)
Es sind die anonymen delegates, die das Ganze etwas wüst aussehen lassen. *lach*
Über die 3 öffentlichen Methoden werden lediglich Statusflags gesetzt. (Ja, es sind 3 und nicht 2 Methoden, weil ich noch eine Methode wollte, mit der ich die Flags wieder zurücksetzen kann.)

In der geschützten "Do" Methode wird lediglich ein neuer EventHandler zurückgegeben. Und in diesem Handler steckt eine Kontrollanweisung, die einfach prüft, welche Rolle der "Mittelmann" im Moment spielt. Ist er ein "Asynchronizer", wird die "customMethod" einfach in den ThreadPool gesteckt. Und nach mir die Sintflut. *g*
Ist er ein "Synchronizer", wird die "customMethod" in die "asyncOp" gesteckt. (Dieses Ding sorgt voll automatisch dafür, dass ein beliebiger Thread mit dem GUI-Thread synchronisiert wird.)
Wenn er letztlich nix von Beiden ist, dann soll die "customMethod" ganz normal aufgerufen werden.

Und weil diese Prüfung bei JEDEM ausgelösten Event durchgeführt wird, könnte man quasi zur Laufzeit der Anwendung das Verhalten ändern.

Also ich finde das richtig geil! Da hier in der grundlegenden Struktur absolut nicht viel geändert werden muss, habe ich das heute auch in sehr kurzer Zeit in meinem Softwareprojekt auf Arbeit aktualisiert. Da habe ich nämlich auch einen Task, der am besten asynchron ablaufen müsste. Das ist jetzt ein Kinderspiel! :-D
Es ist so geil! ^_^

Das soll es auch schon gewesen sein.
Ich habe hier auch ein Visual Studio 2008 Projekt, wo Du das mal ausprobieren kannst: KLICK [rar-Archiv]