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]

1. MPT Beispiel - Teil 2

Nun kommt, wie vesprochen, der 2. Teil meines ersten MPT Beispiels.
Und ich bin direkt froh darüber, dass ich gerade in diesem Teil auf die "Mittelmänner" eingehe! Denn erst heute habe ich einen effektiven Weg gefunden, um ganz einfach die asynchrone und synchrone Nachrichtenverarbeitung zu verwenden. Dazu aber später mehr. (Das wird dann ein extra Beitrag werden.)

Beim letzten Mal hatte ich ja gezeigt, wie einfach das Hauptfenster intern aufgebaut ist.

Heute möchte ich zeigen, was die Komponenten zusammenhält:

Die Mittelmänner

Hier kommt erstmal wieder das Listing des Quellcodes, den ich nachher ausführlicher erklären möchte:

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

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

   Form1 form1 = new Form1();
   AddTextViewModel addTextViewModel =
    new AddTextViewModel(
     new TextViewManager(
      form1));
   
   new AddTextViewMediator(
    form1,
    addTextViewModel);

   new TextViewFrequency(
    addTextViewModel,
    form1);

   Application.Run(form1);
  }
 }
}

Ja, das ist auch schon alles.
Los geht's!

Form1 form1 = new Form1();
AddTextViewModel addTextViewModel =
 new AddTextViewModel(
  new TextViewManager(
   form1));

Ich muss es gleich jetzt sagen: Was du in diesem Ausschnitt siehst, ist Mist! Es funktioniert zwar, aber es ist strukturell einfach nicht zumutbar, wenn du mit den Micro-Pattern entwickelst! Dass ich es so programmiert habe, lag eigentlich nur an zwei Faktoren:
1. wollte ich die Idee nur mal schnell testen, um zu sehen, ob das so funktioniert, wie ich es mir gedacht habe.
2. hing ich gedanklich doch noch sehr an dem originalen "Presenter Fist" Prinzip. Denn dort ist es gestattet, dass konkrete Objekte eigene Abhängigkeiten haben.

Ich will dennoch erklären, was der Code zu bedeuten hat.
In Zeile 18 wird einfach nur das Hauptfenster erzeugt, ist aber noch nicht sichtbar.
In der nächsten Zeile wird das "AddTextViewModel" erzeugt. Dieses erwartet als Konstruktor-Argument ein Objekt, welches sich als "IAmTextViewFactory" bezeichnet. Der "TextViewManager" fungiert als diese "IAmTextViewFactory".
Der "TextViewManager" erwartet ein Objekt, welches sich als "IAmTextTransmitter" bezeichnet. In diesem Falle ist ja das Hauptfenster eben dieser "TextTransmitter".
Die Internas dieses Konstrukts zeige ich im nächsten Teil.

Wie man sieht, ist sogar diese kleine Hierarchie nicht mehr leicht nachvollziehbar. Zudem sind die Objekte wieder miteinander gekoppelt und somit voneinander abhängig. Sowas geht echt gar nicht! Kein Objekt sollte von einem anderen Objekt abhängig sein ... ausgenommen, die "Mittelmänner". Aber die haben selber keine Businesslogik, sondern sind nur für die Infrastruktur da.

Der nächste Abschnitt:

new AddTextViewMediator(
 form1,
 addTextViewModel);

new TextViewFrequency(
 addTextViewModel,
 form1);

So sollte die gesamte Software zusammengesetzt sein! Das ist die saubere Anwendung vom MPT Konzept.
Die Mittelmänner können einfach in den "Raum" hinein erstellt werden.

Sehen wir uns einfach mal an, wie die "Mittelmänner" im Inneren aussehen:

Der Mediator:

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

namespace PFDynamic
{
 public class AddTextViewMediator
 {
  private readonly IAmAddTextViewCaller caller;
  private readonly IAmAddTextViewListener listener;

  public AddTextViewMediator(
   IAmAddTextViewCaller caller,
   IAmAddTextViewListener listener)
  {
   this.caller = caller;
   this.listener = listener;

   this.caller.AddTextView += new EventHandler(caller_AddTextView);
  }

  void caller_AddTextView(object sender, EventArgs e)
  {
   listener.DoAddTextView();
  }
 }
}

Die Frequency:

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

namespace PFDynamic
{
 public class TextViewFrequency
 {
  private readonly IAmTextViewTransmitter transmitter;
  private readonly IAmTextViewReceiver receiver;

  public TextViewFrequency(
   IAmTextViewTransmitter transmitter,
   IAmTextViewReceiver receiver)
  {
   this.transmitter = transmitter;
   this.receiver = receiver;

   this.transmitter.SendTextView += new EventHandler(transmitter_SendTextView);
  }

  void transmitter_SendTextView(object sender, EventArgs e)
  {
   receiver.ReceiveTextView(
    transmitter.ReturnTextView());
  }
 }
}

Soviel gibt es da im Grunde nicht zu sagen, denke ich. Wer C# kann, sollte den Quellcode hier problemlos verstehen. Es ist im Grunde nur Wrapper-Code. Und diesen Code muss man bei jedem Triplet erstellen. Und das langweilt, weshalb hier unbedingt ein RAD-Tool her muss! ^_^

Das soll es für diesen Beitrag gewesen sein.

Jetzt schreibe ich gleich noch den nächsten Beitrag mit den Neuigkeiten, die sich in letzter Zeit bei dem MPT Konzept ergeben haben.

Bis dann! :-)

Ich mache es doch anders ...

Vor ein paar Tagen hatte ich ja geschrieben, dass die Fortsetzung des MPT-Beispiels etwas warten muss, weil ich das RAD-Tool aktiv entwickeln möchte.
Ich werde es aber doch so machen, dass ich erst noch das MPT-Beispiel komplett erkläre. Das ist so besser, weil dann erstmal eine Basis dafür existiert, wie die Sache in der Praxis aussieht.

Umso spannender (ich hoffe es jedenfalls *g*) wird es dann nach dem Beispiel werden!
Ich habe nämlich vor, den Fortschritt des RAD-Tools per Video zu protokollieren. Es soll aber keine Schritt-für-Schritt Anleitung werden, sondern ich möchte nur kurz die Features vorstellen und erklären, wie diese funktionieren. Das werde ich sicher auch mal mit Diagrammen veranschaulichen.
In jedem Beitrag werde ich dann auch noch den Versions-Hash von dem entsprechenden Git-Commit hinterlassen, damit man später irgendwann mal leicht nachvollziehen kann, zu welcher Version das Video gehört.
Ich denke, das ist mal was anderes.
Ich, persönlich, liebe es ja, zu verfolgen, wie eine Anwendung wächst und an Features gewinnt. (Das war z.B. auch ein Grund, weshalb ich schon möglichst zeitig zu Google Chrome gegriffen habe. Da waren ja, verglichen mit Firefox, noch kaum Features drin. Oder die Entwicklung von Blender verfolge ich z.B. auch schon, seit es noch zu "Not a Number" gehörte. Ja, einer Anwendung beim Wachsen zuzusehen ist echt aufregend!)

Momentan ist "Atomix" ja noch in einem sehr frühen (und nicht wirklich brauchbaren) Stadium. Aber es besitzt dennoch schon genug, um diesen ersten Iterationsschritt per Video vorzustellen. Ich kann z.B. Dateien laden und diese in einer Listbox anzeigen, welche sich in einem eigenen Toolfenster befindet. Über einen Menüpunkt kann ich dieses Fenster beliebig öffnen und schließen.
Das zeige und erkläre ich aber alles in dem Video genauer. Es ist aber alles unter Zuhilfenahme der MPT entstanden.
"Atomix" wird auch eher evolutionär wachsen. In der ersten Iteration werden die Features noch statisch bzw. spezifisch sein, um zunächst festzustellen, ob es so funktioniert. In der nächsten Iteration werden die Features dynamischen Charakter haben bzw. abstrakter sein. So ist es z.B. auch momentan bei der Dateiansicht. Sie befindet sich momentan im ersten Iterationsschritt. (Genaueres dazu später in dem Video.)


Dann muss ich unbedingt noch etwas berichten!

Heute wurde ich von Ralf Westphal per eMail kontaktiert und erhielt ein interessiertes Feedback. Er verwies mich auch auf seine Idee der sogenannten "Event-based Components". Unsere Ideen sind im Grunde identisch! Das heißt, wir beide streben ein Konzept an, womit man auf einfache Weise durch völlige Entkopplung der Aspekte seine Anwendung agil und flexibel entwickeln kann.
Man sollte sich seine Ideen dazu wirklich mal ansehen! Gerade seine Grafiken sind sehr anschaulich.
Was auf den ersten Blick auffällt, ist, dass er regen Gebrauch der neuen C# Features macht.
Ich halte mich dabei noch an die Version 2.0, weil ich auf Arbeit auch noch mit Visual Studio 2005 Professional auskommen muss. Und mein Konzept möchte ich in erster Linie für die Arbeit nutzen. Daher ist das etwas problematisch, mich zu sehr auf die neuen Features einzulassen. Man ist dann schnell davon verwöhnt.
(So brachte mich z.B. die erste richtige Konfrontation mit C# direkt von C++ ab. C/C++ fasse ich nicht mehr freiwillig an. Nur, wenn es wirklich sein muss.)

Zudem bin ich überrascht, dass solche Ideen zur Abwechslung mal aus dem deutschsprachigen Raum kommen. Damit hätte ich absolut nicht gerechnet!

Wir wollen auf alle Fälle weiterhin Kontakt halten und Ideen austauschen.

Aber ich bin wirklich froh, dass es noch mehr Leute gibt, die sich über die Zukunft der Softwareentwicklung Gedanken machen! :-)