Der Sachsen-Coder

OOP und Flow Design sind wie Yin und Yang

noreply@blogger.com (Anonymous) — Mon, 10 Sep 2012 21:57:00 +0000

Je mehr ich in meinen Projekten Flow Design mithilfe der Event Based Components anwende, umso mehr stelle ich fest, dass auch die konventionelle Objektorientierte Programmierung sehr gut in das Konzept passt.

Das merke ich gerade besonders bei meinem "Talisa" Projekt. Seit einigen Tagen bastle ich intensiv an der Parser-Funktionalität.

Im Groben funktioniert das ja so, dass man drüben eine Zeichenkette reinsteckt und am anderen Ende kommt ein vollständiger abstrakter Syntaxbaum heraus. Sich das als Flow vorzustellen, ist eine Wohltat für die Hirnzellen. Und so habe ich das auch aufgebaut. Bis ich an den Punkt kam, als es darum ging, die Token-Liste zu parsen. Das ist alles andere als trivial, wenn man es ordentlich machen will.

Natürlich wollte ich das auch erst pur im Flow Design Stil angehen. Aber als ich begann, einen kleinen Plan zu schmieden, wie ich das am Besten umsetze ("Also erst müsste es dort hin fließen, dann kommt das dort hinein, dann ... Mist, da brauche ich wieder shared state, dann geht das wieder dort hin ... oh Gott!"), resignierte das Hirn schnell, indem es zu verstehen gab: "Boa, nee ... das ist doch nicht Dein Ernst, oder?! Das ist voll kompliziert, darüber nachzudenken! OOP fühlt sich hier viel besser an!"

Tatsächlich hatte ich auf Anhieb eine bessere Vorstellung von einer Lösung im OOP-Stil. Zwar noch nicht konkret, aber ich wusste, wie ich meine sogenannte "FlowPattern"-Komponente am liebsten verwenden möchte. Aber diese OOP-Komponente steckt völlig isoliert in meiner Flow-Komponente mit der Bezeichnung "Create_Flow_Ast". (Der verlinkte Quellcode ist noch völlig Work-In-Progress. Wie gesagt, ich bastle gerade noch am Parser.)

Ich hatte auch schon des öfteren vergessen, dass ich mich in einer einzelnen Flow-Komponente befinde, aufgrund der Isolierung. ;-)

Wann verwende ich(!) Flow Design und wann OOP?

Ja, die Betonung liegt hier auf "ich", weil es bei anderen Entwicklern wieder ganz anders sein kann. Die Liste kann aber als grobe Orientierung dienen, falls man noch nicht so das Gefühl dafür hat.

Flow Design:

Beliebige rohe Daten müssen in abstrakte Datenstrukturen gebracht werden. Und dies kann in mehreren Etappen erfolgen.
Man verwendet Closed-Source Komponenten oder fremden Code. Den sollte man sauber in eine Flow-Komponente stecken.
Man kann sich sehr gut vorstellen, bestimmte Bereiche seines Codes asynchron ablaufen zu lassen. ➜ Diese Komponenten sollten in isolierte Flow Einheiten gesteckt werden!
Es geht allgemein um Threads und asynchrone Verarbeitung? ➜ Flow, Flow, Flow und nochmal Flow! Ich kann das nicht oft genug betonen, weil Threads echt fies sein können. Ich bin schon oft ein Opfer von ihnen geworden. (So verrückt kann man gar nicht immer denken, welche Schlupflöcher diese "Biester" immer wieder finden. *g*)
Daher: Jegliche Funktionalität von Threads getrennt halten. Threads isoliert halten und nur durch Flow-Eingänge und -Ausgänge an die zu erledigenden Aufgaben führen!
Wann immer man vor seinem geistigen Auge einen Flow erkennen kann. Wenn das Lösen eines Problems durch Flow Design geradezu natürlich und einfach erscheint ... wenn das Nachdenken nicht sonderlich anstrengt, sondern im Gegenteil, es einen regelrecht mitreißt! Warum dann seine Zeit und Energie mit OOP verschwenden?

OOP:

Die Verarbeitung ist komplexer und lässt sich eher umständlich und unübersichtlich als Flow beschreiben.
Die Lösung für ein Problem ist in sich geschlossen, untrennbar und atomar. Warum soll man hier auf OOP verzichten?
Man hat etwas Hierarchisches, was irgendwie verarbeitet werden will.
Die Usability (aus Entwicklersicht) kann durch Verwenden von OOP deutlich verbessert werden. (Siehe mein "FlowPattern"-Beispiel von oben.)
Es ist nicht beabsichtigt bzw. nicht sinnvoll, Funktionalitäten innerhalb der Komponente asynchron ablaufen zu lassen. (Wieder mein "FlowPattern" als Beispiel: Es ist weder sinnvoll, noch beabsichtigt, irgendwelche Threads innerhalb dieser Komponente hantieren zu lassen. Das wäre mehr als gefährlich!) Somit kann man getrost OOP nutzen, wenn ein gegebenes Problem dadurch leichter zu lösen ist.
Wann immer man vor seinem geistigen Auge eine Interaktion von Objekten erkennen kann. Wenn das Lösen eines Problems durch OOP geradezu natürlich und einfach erscheint ... wenn das Nachdenken nicht sonderlich anstrengt, sondern im Gegenteil, es einen regelrecht mitreißt! Warum dann seine Zeit und Energie mit Flow Design verschwenden?

Abschließend noch einige Zitate von Bruce Lee, die man auf die Essenz dieses Beitrags gut projizieren kann:

"An der Kampfkunst ist nichts Geheimnisvolles. Nimm die Dinge wie sie sind: Schlage, wenn du schlagen mußt, tritt, wenn du treten mußt."

"Der leichte Weg ist auch der richtige Weg."

"Meine Bewegungen sind einfach, direkt und nicht-klassisch."

Bildquelle "Yin Yang": Wikipedia;
Zitatquelle: http://www.bruce-lee-jeet-kune-do.de/bruce-lee/zitate.html

Project Talisa

noreply@blogger.com (Anonymous) — Mon, 27 Aug 2012 18:42:00 +0000

Eines vorweg: Project Jessica ist nicht tot! Es liegt vorerst nur auf Eis.

Project Talisa?
Hierbei handelt es sich um den Versuch, eine IDE für Flow Design orientierte Software zu erstellen.
Die Basis bzw. der gemeinsame Nenner wird die "Flow-Beschreibungssprache" von Ralf Westphal sein.

Eine konkrete Idee, wo die Reise hingehen wird, habe ich aber noch nicht direkt. Es wird sich entwickeln.
Aber was mir so vorschwebt, sind automatisch generierte Diagramme und Quellcode Dateien.
Importieren von Quellcode Dateien soll später auch mal möglich sein. Und natürlich auch das direkte Bearbeiten des Flows im Diagramm.
Eine art Simulationsmodus schwebt mir da auch noch vor. Eventuell sogar eine Flow Analyse oder so.

Am Ende will ich mit der IDE meinem Ziel näher kommen, Software zu modellieren. (Bitte nicht mit UML Modellierung verwechseln! Das ist zu sehr vorbelastet und man denkt dabei an "umständlich" und "kompliziert". Man sollte eher an das Modellieren von 3D Grafik Modellen denken. *g*)

Was ich bei dem Projekt anders machen will, als bei Jessica

Weniger faseln, sondern mehr coden! Ich schreibe zwar auch sehr gerne (zu gerne sogar), aber davon entsteht leider keine Software. Das ärgert mich zwar selber, aber ich muss da Prioritäten setzen.

Es gibt nix Perfektes! Der Tatsache muss ich einfach immer wieder ins Auge blicken! Ich will es nicht wahr haben, aber so ist es. Ich will immer alles perfekt machen, aber das lähmt ungemein. Die Gedanken kreisen ständig um Kleinigkeiten. Man kommt sich vor, als ob man versucht Ort und Impuls von Quantenteilchen gleichzeitig bestimmen zu wollen. Aber es funktioniert nicht.
In der Softwareentwicklung ist es das Selbe. Man kann zwar versuchen, ein Optimum zu erreichen, aber man wird immer irgendwelche Kompromisse eingehen (müssen), die einfach "hässlich" sind.
Und so werde ich mich auch nicht zu sehr damit belasten, eine Perfektion zu erreichen. Wie es wird, so wird es. Hauptsache, es gibt was Funktionierendes. Das bringt mich zum nächsten Punkt ...

Ship early and often! Mal sehen, ob ich das einhalten kann. (Hier spielen ja auch die Faktoren "Zeit" und "Motivation" eine Rolle.)
Man kann das aber auch so an vielen Open Source Projekten beobachten. Erfolgreich sind die Projekte, wo es schnell vorwärts geht. Auch diese Projekte sind oft weit weg von "Perfekt", aber man kann die Evolution erkennen. Da ist was in Bewegung und man weiß, dass man für das nächste Release nicht erst ein Jahr warten muss. Um das zu erreichen, muss man bereit sein, die Illusion der Perfektion hinter sich zu lassen.

Wird gefrickelt? Schon möglich. Das heißt, es gibt keinen direkten Plan, wie ich bei dem Projekt vorgehe. Es ist auch möglich, dass ich eventuell das Rad neu erfinde, weil ich eine gewisse Technologie noch nicht verstanden habe und es in meinen Augen einfach schneller geht, wenn ich es für meine Bedürfnisse selbst implementiere.

Kurzum: Ich will auch für mich persönlich schnell Features haben, die ich produktiv nutzen kann. Zudem sehe ich das Projekt als Experiment, wie eine neu IDE aussehen könnte und was für Möglichkeiten realisierbar sind.

Warum der Name "Talisa"?
Aus dem selben Grund, wie ich das andere Projekt "Jessica" genannt habe. Ein Name, wie z.B. Flow(er)IDE oder sowas, klingt irgendwie abgedroschen und hat man irgendwie schon mal gehört. Ein einfacher femininer Name passt. Wer will, kann ja bei der Google Bildersuche mal nach Talisa suchen. ^^

Bleibt eigentlich nur noch zu sagen, dass man das Projekt bei GitHub findet.
(Dank "GitHub for Windows" habe ich Git nun auch halbwegs im Griff. *g*)

Tja, dann guck mer mal. ;-)

Project Jessica - Datenverwaltung

noreply@blogger.com (Anonymous) — Sun, 05 Feb 2012 18:18:00 +0000

Ein wesentlicher Aspekt der Software wird die Datenverwaltung sein.
Ich habe lange überlegt, ob ich eine fertige Datenbanklösung nehme oder etwas Eigenes entwerfe, was exakt auf meine Bedürfnisse zugeschnitten ist.
Mir wurde empfohlen, vielleicht besser eine bestehende dokumentenorientierte Datenbanklösung zu verwenden. MongoDB wirkte auf mich erstmal sehr attraktiv und ausgereift. Aber dieses Datenbanksystem bringt standardmäßig ca. 65 MB auf die Waage. Da stehen noch keine Nutzerdaten drin. Das ist der gewöhnliche Overhead.
Das ist mir ein bisschen schwergewichtig.
Ich hatte mich auch mal umgesehen, was es sonst noch so für NoSQL-Datenbanken gibt. Da gibt es ja enorm viele. Stichprobenartig habe ich mir auch mal die ein oder andere genauer angesehen. Da hat jede so ihre Vor- und Nachteile. Die eine ist kommerziell, die andere vom Background her zu kompliziert, zu schwergewichtig, hat keine offizielle .NET-API, oder, oder, oder.
Ich möchte damit nicht die Leistung der Datenbankentwickler schmälern, die da sehr viel Zeit und Know-How investiert haben. Ich brauche aber eher was Einfaches, speziell Zugeschnittenes, ohne generischen full fledged Datenbank-Wrapper.

Eine Kleinigkeit hatte ich nämlich vergessen zu erwähnen: Jessica soll keine umfangreiche Installation erfordern oder sich ins System einnisten, um zu funktionieren. Sie soll portabel sein.
Entpacken ... ausführen ... glücklich sein! ^_^

Alle relevanten Daten, die sie im Laufe ihres Lebens anlegen muss, landen in einem einfachen Unterverzeichnis direkt neben "ihr".
Das hat, wie ich finde, mehrere Vorteile:

Man weiß, wo sich die Daten befinden. Oft ist es schwierig, bei anderer Bildverwaltungssoftware, den Ort der erzeugten Daten zu lokalisieren. (Vielleicht befinden sie sich im AppData-Verzeichnis oder doch woanders?!)
Man kann leichter experimentieren. So benennt man nur den Datenordner um, startet die Software neu und sie verhält sich so, als würde sie zum allerersten mal gestartet. Danach könnte man diesen "Testordner" wieder löschen ... nennt den anderen Ordner wieder so wie vorher ... startet Jessica und alles ist so, als wäre nie etwas gewesen.
Es sind ganz einfach vollständige Backups möglich. Das ergibt sich auch durch den zweiten Punkt.
Bilder und Software zusammen mitnehmen. Zum Beispiel, wenn man auf einer externen Festplatte seine ganzen Bilder hat, könnte man dort auch die Jessica inklusive ihrer Daten drauf kopieren. Woanders könnte man dann die Bilder problemlos mit der voll eingerichteten Software betrachten, vorführen oder organisieren.

Solche Dinge, wie die Sache mit den Backups oder so, kann man auch direkt in die Software integrieren. Auf lange Sicht soll sie sehr DAU-freundlich sein.

Nun zur eigentlichen Datenverwaltung:

Ich versuche die Sache pragmatisch anzugehen. Ich möchte in erster Linie (Medien)-Dateien verwalten. Punkt.

Jede Datei besitzt ja von Haus aus einen Dateiname. Diese Datei kann auch noch in einem Ordner liegen. Zusätzlich gibt es zu jeder Datei mögliche Tags bzw. Schlagworte.

(Klar, diverse Medienformate haben noch viel mehr Metadaten zu bieten. Aber die interessieren mich am Anfang eher weniger, weil ich ja kein Profi-Fotograf bin. Wenn aber die Software soweit ist, dass sie z.B. nach Tags exakt filtern kann, werden auch noch andere Metadaten hinzukommen.)

Es gilt also erstmal strikte Komplexitätsreduktion und Fokus auf das Wesentliche:

Dateinamen
Dateinamenerweiterungen
Ordnernamen
Tags

Nach diesen Dingen soll am Anfang gesucht werden können. Das wäre dann so ähnlich, wie es bei Picasa der Fall ist.

Nun habe ich mich die letzten Tage (bzw. Wochen) immerzu mit diesem Aspekt gedanklich auseinandergesetzt. Ich habe recherchiert und bin dabei immer wieder auf B-Trees gestoßen. Diese Struktur scheint sich bei Datenbanken durchgesetzt zu haben. Eine Implementation für C# habe ich auch gefunden.

Es gibt aber noch eine Sache, die mich doch sehr beschäftigt:
Wie kann man effizient nach Dateien oder allgemein nach Stichworten suchen? Wie organisiert man sowas strukturell?
Das Einfachste wäre ja, man sortiert sie alphabetisch. Das Problem ist aber, dass man im seltensten Fall eine Datei alphabetisch sucht. Man sucht ja eine Datei viel öfter nach ihrem ungefähren Wortlaut. Gerade, weil man nicht mehr genau weiß, wie sie hieß.
Also kann man IMHO nicht einfach alphabetisch sortieren und danach indizieren. Man müsste jeden Buchstabe von einem Dateiname indizieren.
Um das anschaulicher zu machen, habe ich einige Grafiken angefertigt, mit denen ich ein Beispielszenario durchgehe.

Nehmen wir mal an, es gibt ein Bild, welches "Jessica" heißt. (Der Einfachheit halber verzichte ich hier auf Dateiendungen.)
Schematisch dargestellt, teilt sich der Name in folgende Buchstaben auf:

Jeden Buchstabe würde ich einzeln indizieren, sodass jeder Buchstabe auf die Datei verweist.
Hierzu müssen aber redundante Buchstaben entfernt und eine alphabetische Ordnung hergestellt werden. Wie ich mir das vorstelle, sieht man im nächsten Bild in der obersten Reihe:

Die oberste Reihe kann man sich wie eine Liste bzw. wie ein Dictionary vorstellen. In einem Suchfeld könnte ich einen der Buchstaben aus der obersten Reihe eingeben und bekäme als Suchergebnis mindestens auch die "Jessica"-Datei angeboten.
An jedem Buchstabe aus der obersten Reihe könnte wieder eine Liste oder eine Graph-Struktur hängen. In der Struktur sind dann wieder Buchstaben hinterlegt, welche auf die "Jessica"-Datei verweisen.
Die Pfeile geben eine valide Buchstabenfolge wieder, mit der man die "Jessica"-Datei finden kann.
Gebe ich also "ICA" in das Suchfeld ein, bekomme ich als logische Konsequenz die "Jessica"-Datei angezeigt, weil diese Buchstaben in der Reihenfolge im Dateiname vorkommen.
Würde ich aber "ICAB" eingeben, so bekäme ich die Datei nicht angezeigt, weil diese Buchstabenfolge nicht im Name vorkommt. Nach dem Knoten "A" kommt nix mehr. Beim Buchstabe "S" gibt es zwei mögliche Wege, bedingt durch das doppelte Auftreten dieses Buchstaben im Name.

Wie sieht das Ganze aus, wenn ein Dateiname hinzukommt? Um das ganze interessanter zu machen, habe ich einen Name gewählt, der sich mit "Jessica" überschneidet. Die andere Datei heißt "Jennifer".

Zur besseren Unterscheidung sind die Knoten von "Jennifer" blau.
Das folgende Bild zeigt die alphabetische Anordnung aller Knoten inklusive der Knoten von "Jessica":

Das Gebilde sieht schon interessanter aus. Buchstaben, welche beide Namen gemeinsam haben, habe ich anders eingefärbt, um sie besser hervorzuheben.
Nun ist der Graph schon bei zwei Namen so umfangreich geworden. Logisch! Gerade am Anfang würde er immer stark anwachsen, weil es sehr wahrscheinlich ist, dass es bestimmte Buchstaben- und Zeichenkombinationen noch nicht gibt. Das Wachstum wird sich aber abschwächen, je mehr Dateinamen es gibt. Pro Knoten wird es dann nur mehr Indexverweise geben. Das Auffinden einer beliebigen Datei sollte aber verhältnismäßig schnell gehen. In dem obigen Beispiel müsste man im schlechtesten Fall 3 Buchstaben eingeben, um eine Datei eindeutig zu finden. Im besten Fall reicht ein Buchstabe. Ein Knoten referenziert aber immer eine exakte Indexmenge. Das heißt, die Resultate könnten sofort abgerufen werden. Das würde sicher erstmal viel Redundanz verursachen. Aber vielleicht ließe sich da später noch was optimieren.
Eine Möglichkeit fiele mir schon ein. In dem obigen Beispiel bräuchte man nur 3 getrennte Index-Cluster und nicht für jeden Knoten einen eigenen.

Ich hätte zumindest keine Idee, wie man sonst effizient nach bestimmten Dateien anhand von Wortfragmenten suchen will.
Ich müsste das einfach mal in der Praxis ausprobieren und dann sehen, ob mir das überhaupt Vorteile bringt.
Vielleicht habe ich mich auch komplett in eine Sackgasse verrannt. Erst recht, weil ich schon zu lange über diese Problematik nachdenke und dadurch noch nix umgesetzt habe.

Vielleicht sollte ich mich mit diesem Aspekt der Datenverwaltung noch gar nicht heiß machen. Ob ich am Ende eine eigene Verwaltung implementiere oder doch ein bestehendes Datenbanksystem verwende, kann im Grunde noch offen bleiben. Die Architektur soll auf jeden Fall so aufgebaut sein, dass dieser Aspekt jederzeit ausgetauscht werden kann.

Strategisch günstiger wird es sein, wenn ich das Projekt von ganz oben beginne: beim User Interface.
Vor allem hätte man dadurch schon am Anfang sichtbare Fortschritte. Wenn dann erst mal das Gefühl für die Usability da ist, wächst der Rest so allmählich hinein.

Als nächstes werde ich also erstmal Mockups skizzieren, wie ich mir das GUI vorstelle. Dann habe ich auch ein Gerüst, wenn ich das in XAML kodiere. Ein Mockup ist schnell mal verworfen oder verändert.

Bis dann.

Project Jessica - Vorbereitung

noreply@blogger.com (Anonymous) — Sun, 22 Jan 2012 16:06:00 +0000

Wie wird die Versionierung aussehen?
Ist das "Big Picture" nach meinem Empfinden erreicht, bekommt Jessica die Version 1.0.
Die Schritte dahin werden in Iterationen zerlegt. Und Iterationen werden in Slices zerlegt.

Angenommen, es gibt die Version 0.3.2, dann heißt das, es ist die 3. Iteration mit dem 2. Slice auf den Weg zum "Big Picture".

Definition "Iteration"
Eine Iteration beinhaltet eine Funktionalität, mit der man schon etwas Sinnvolles anfangen kann. "Sinnvoll" ist natürlich relativ. Im Falle von Jessica ist der erste Schritt insofern sinnvoll, weil ich ein oder mehrere Ordner importieren kann und mir ALLE gefundenen Bilder angezeigt werden können, bzw ich durchscrollen kann.

Definition "Slice"
Ein Slice ist ein kleines Häppchen auf den Weg zur ersten sinnvollen Funktionalität. Nur für sich genommen ist ein Slice nicht sinnvoll. Um beim obigen Beispiel zu bleiben, ist es nicht sinnig, wenn ich einen Ordner importieren könnte, aber es würde nix angezeigt werden.
Aber der Slice ist wichtig, um die Komplexität aus Entwicklersicht zu reduzieren und um die Motivation zu erhalten.

Wie viele Iterationen oder Slices es geben wird, steht noch nicht fest. Das hängt von der Komplexität des angestrebten Features ab.

Das Repository
Vorgestern habe ich das Git-Repository bei GitHub eingerichtet.
Man findet es dort: https://github.com/SachsenCoder/Jessica

Mit der Schritt-für-Schritt-Anleitung von GitHub war das Einrichten sehr einfach. Ich hatte nur lokal ein kleines Problem mit der "Git Bash", weil die Konsole kein UTF-8 darstellen wollte. (Mein Nachname hat ja das "ö" an zweiter Stelle.)
Naja, ich habe mich dann für die Git Extensions entschieden. Das Tool nutzte ich auch sonst ganz gerne für meine lokalen Repositories. Damit war das UTF-8 Problem auch gelöst. ^^

Wie geht es weiter?
Gestern hatte ich die echte Jessica vektorisiert: http://fav.me/d4n56c4
(Sowas brauchte ich auch mal wieder. Das hat was Entspannendes.)

Als nächstes werde ich erstmal ein paar Spikes entwerfen. Das betrifft einmal das GUI und die "Datenbank".
Datenbank deshalb in Anführungsstrichen, weil ich erstmal selber eine Idee testen will. Eine richtige universelle Datenbank wird das nicht und ist auch gar nicht beabsichtigt.
Wie ich mir das vorstelle, wird in einem weiteren Beitrag beschrieben.
Die Spikes werde ich auch in das Repository packen. Die gehören immerhin zur Entwicklung dazu. ;-)

Bis dann! :-)

Project Jessica - Vorstellung

noreply@blogger.com (Anonymous) — Thu, 19 Jan 2012 22:28:00 +0000

Ich muss mich jetzt quasi outen, da es sonst für Außenstehende keinen Sinn ergeben würde, weshalb gerade ich eine solche Software brauchen sollte.

Ich besitze ca. 269 Tausend Mediendateien (Videoclips und Bilder zusammen) verteilt auf etwa 3.713 Ordnern mit fast 310 GB, kann mich nur schwer von einem Bild trennen, aber fotografiere selber so gut wie gar nicht.

Die große Preisfrage:
Wie komme ich zu so einer menge Material? Wer oder was bin ich? ;-)

Ich glaube, ich bin ein Bildermessie oder sowas. Ich denke manchmal, dass das echt schon krankhaft ist.
So habe ich z.B. einen Ordner, wo nur Bilder von deviantArt drin sind ... ca. 16 Tausend Bilder, rund 21,9 GB überwiegend High-Quality. Alles manuell runtergeladen. (Gott, wenn ich mir das mal auf der Zunge zergehen lasse. Die Tabs vom Google Chrome Browser haben da schon des öfteren den Geist aufgegeben, weil zu viele HQ Bilder gleichzeitig geöffnet waren. Und die Flash-Instanzen schlugen auch noch zu Buche. Ich glaube, der Chrome Browser selber ist da auch schon mal komplett abgeschmiert. *g*)
Oder meine Sammlung weiblicher Promis: 21.343 Dateien verteilt auf 448 Ordner (ca. 10,8 GB).

Da bin ich natürlich scharf auf gute Bildverwaltungsprogramme, denn es werden sicher nicht weniger Bilder. Eher noch mehr.
So manches Tool kam mit der Menge gar nicht zurecht, weil das nur auf wenige Bilder ausgelegt war. (So in der Größenordnung von wenigen Hundert bis Tausend oder so. Also, was der Otto Normaluser so mit seiner Digicam produziert.)
Andere Tools brechen zusammen, wenn man mal um die 30 Tausend Bilder als Slideshow in zufälliger Reihenfolge abspielen lassen will. -.-
Oder beim Photoshop Elements Organizer: Das Tool machte Anfangs wirklich einen guten Eindruck. Mal um die Tausend Bilder in einen Katalog eingelesen. Ging ganz gut. Vor allem die Filtermöglichkeiten und die Smartalben hatten mich erstaunt. Sowas wollte ich schon immer mal haben. Also hatte ich es gewagt: Er sollte meinen ganzen Bestand einlesen. "ACH DU SCHANDE! Was ist denn jetzt los?" sagte ich so zu mir. Da hat der mir echt einen modalen Progressdialog angedreht, wo es nur die Möglichkeit zum Abbrechen gab. Naja, muss es eben so sein. Ich glaube, der war fast den halben bis dreiviertel Tag damit beschäftigt, die Medien einzulesen. Wäre ja alles nicht so schlimm gewesen, wenn er das im Hintergrund gemacht hätte. Als er denn dann endlich fertig war, hat er mir erstmal gesagt, was er alles nicht einlesen konnte. Das präsentierte er mir in einem winzigen Dialog in einer noch winzigeren Listbox, wo ich mir dann die fehlgeschlagenen Dateien ansehen konnte. Gut, vielleicht waren da wirklich ein paar Beschädigte dabei. Oder es handelte sich zum Teil auch um Zip-/Rar-Archive. Soviel ich noch weiß, hat er mal aufgrund der fehlerhaften Dateien den Vorgang mittendrin abgebrochen. Da hatte ich dann letztlich immer nur eine Hand voll Ordner gleichzeitig eingelesen. Das hat er einigermaßen verkraftet. Aber selbst der restliche Umgang mit der Datenmenge hat keinen Spaß gemacht. Immer wieder wurde man vom GUI abgehalten, etwas zu tun, weil es blockierte. Das war eine sehr grausige Software (für meine Bedürfnisse).
Tja, meine bisherigen Favoriten sind Picasa und die Windows Live Fotogalerie. Die kommen spielend mit großen Datenmengen klar. Aber denen mangelt es massiv an komfortablen Verwaltungsfunktionen, wie ich sie gerne hätte.

Nun wollte ich eigentlich warten, bis diese Tools irgendwann mal Smartalben oder mächtige Filtermöglichkeiten haben. Aber da kann ich vielleicht noch lange warten. Entweder wollen das wirklich nicht viele Leute, oder sie wissen gar nicht, was Smartalben sind.

Nein, jetzt reicht's! Ich brauche die Features sehr bald. Ich will endlich mal Ordnung in meine Bild- und Videoclip-Bestände bringen!
Also gibt es nur eine Lösung: Selber machen!
Jene Software wird auf den Name Jessica hören!

Jessica - Die Bildverwaltungssoftware für anspruchsvolle Sammler

Wird meine Software am Ende
auch mal so attraktiv sein,
wie die echte Jessica?

Warum gerade der Name "Jessica"?
Wenn ich den Name höre, muss ich unweigerlich an Jessica Alba denken. ^_^
Und das wird mir immer vor Augen halten, dass meine Software "Jessica" auch sexy und menschlich werden soll! Mit "menschlich" meine ich hier speziell die Mensch-Maschine-Interaktion. Software und Hardware sollten sich doch dem Menschen anpassen und nicht umgekehrt. Aber das werde ich im weiteren Verlauf noch genauer erläutern, was mir da so vorschwebt.
Generell werde ich versuchen, neue Pfade zu beschreiten. Ob mir das gelingen wird, weiß ich nicht. Aber die Vision ist an der Stelle wichtig und dass man darauf hin arbeitet. Warum sollte man sich mit weniger zufrieden geben? Was Microsoft, Apple, Google & Co. entwickeln, ist doch nicht das Ende der Fahnenstange an Möglichkeiten.

The Big Picture
OK, nun das "Big Picture". Ich glaube, das kann man wörtlich nehmen, bei dem, was die Jessica am Ende alles können soll:

"100 Bilder? 100.000 Bilder? 1.000.000 Bilder oder noch mehr? ... Die Menge spielt für mich keine Rolle!"
Es liegt auf der Hand, dass Jessica spielend mit beliebig vielen Bildern umgehen können soll. Das ist soweit nix Besonderes, denke ich. Ich denke mir, Picasa und die Windows Live Fotogalerie können das auch.

"Was? Du suchst altmodische, statische Alben? Bei mir sind die Alben intelligent, dynamisch und beliebig kombinierbar!"
Hier wird es schon interessanter. Das soll nämlich so ein Killer-Feature werden.
Es wird nach wie vor möglich sein, ein statisches Album anzulegen, wenn man denn unbedingt möchte. Aber bei der Jessica sollen solche Alben intern nur Smartalben mit einer fixen Bildermenge sein. Da wird es aus struktureller Sicht keinen Unterschied geben.
Aber die Stärken sollen sich erst offenbaren, wenn man die Bilder detailliert mit Tags beschrieben hat. Heutige Tools ermöglichen zwar auch, seine Bilder ausführlich zu taggen ... ja, man sagt sogar, je ausführlicher ein Bild getagged ist, desto besser findet man es wieder. Das hatte ich auch immer gedacht. Daher hatte ich damals auch begonnen, meine Bilder sehr ausführlich zu taggen.
Dann wollte ich natürlich mit den Filtermöglichkeiten spielen: Zeige mir die Bilder, welche Tag "X" haben, aber nicht Tag "Y" ... zusätzlich können hier noch Bilder reinfallen, welche Tag "M" haben, aber auf keinen Fall dürfen Bilder angezeigt werden, welche Tag "P" haben.
Bei sowas stößt man bei der gängigen Software schnell an seine Grenzen und ist dann sehr enttäuscht. Da nützen ja die ganzen detaillierten Tags nix, wenn ich nicht exakt das rausfiltern kann, was ich will.

Die Smartalben sollen aber noch mehr können: Man soll vorher Filterregeln für die Smartalben festlegen können. (Soweit nix Besonderes.) Also z.B.: Enthält Tag "X", aber nicht Tag "Y". Dann soll es möglich sein, ein beliebiges Bild in dieses Album zu ziehen, woraufhin die Tags von dem Bild so angepasst werden, dass sie logisch in dieses Smartalbum passen. Das soll aber nur optional geschehen. Denn es kann ja auch die Möglichkeit geben, dass dieses Bild zur fixen Menge hinzugefügt werden soll. Vielleicht löse ich das so, dass da bei dem Smartalbum dann diese zwei Möglichkeiten aufblubbern, wenn man die Bilder darauf zieht.

"Mit mir wirst du keine Tagging-Probleme mehr haben!"
Neben normalen Tags soll es auch hierarchische Tags geben. Diese soll man so handhaben können, als würde man mit richtigen Ordnern arbeiten. Man soll somit Tags verschieben, kopieren und umbenennen können. Alles soll sich unmittelbar auf die Dateien übertragen, welche die betroffenen Tags besitzen.
Es soll auch möglich sein, bestehende Tags, die hierarchisch angeordnet sind, importieren zu können. Dabei soll das Trennzeichen keine Rolle spielen. Für hierarchische Tags nimmt ja heutzutage jede Software ein anderes Format. Die einen verwenden den Slash, die anderen den Backslash, wieder andere einen Bindestrich, etc.
Jessica soll mit jedem denkbaren Format umgehen können. Ebenso soll es möglich sein, in jedes beliebige Tag-Format zu exportieren. Denn, wenn ich einmal ein Bild getagged habe, möchte ich das nie wieder taggen müssen, nur weil eine andere Software mit dem Format nicht klar kommt.
Bei Bildern, wo man die Tags nicht direkt einbetten kann, werden sie extern abgelegt und verwaltet.

"Im Vollbildmodus und bei den Slideshows bekommst du das zu sehen, was du wirklich willst und wie lange!"
Es ist ja wirklich deprimierend. Es gibt so viele Bilder, welche selbst die Full-HD Auflösung locker übersteigen. Sieht man sie sich dann im Vollbildmodus an, hat man trotzdem nur zwei Möglichkeiten: Entweder so im Ganzen zu betrachten, oder rein zu zoomen und dann wie ein irrer hin und her zu scrollen, um den ein oder anderen Bereich in seiner vollen Detailtiefe zu sehen. Und beim nächsten mal geht das gleiche Spiel von vorne los.
Warum kann man die relevanten Bereiche des Bildes nicht markieren und speichern? Und wenn man beim nächsten mal wieder das Bild ansieht, kann man durch einfache Maus- oder Tastatureingaben die Bereiche sofort anspringen. Oder man baut sich so etwas wie eine Collage aus den verschiedenen Ansichten und kann diese ebenso einfach abrufen. Das alles wird nur als Projektionsinformation gespeichert und nicht als neues Bild.
Dann die Slideshows: Ich frage mich, warum die manchmal so wenige Optionen haben. Bei manchen Programmen gibt es eine Shuffle-Funktion, aber keine "Endlos"-Funktion. Oder umgekehrt. Bei Jessica soll es mindestens Beides geben. Und warum kann man das Intervall nicht für jedes Bild individuell setzen?
Mir schwebt da so eine art "Aufnahme"-Funktion vor. Während ich die Bilder manuell betrachte, soll einfach alles Mögliche aufgezeichnet werden. Verweildauer auf einem Bild ... Pan und Zoom, etc. Danach soll man auch noch die Möglichkeit haben, die "Aufnahme" zu bearbeiten, um uninteressante Stellen zu entfernen oder zu modifizieren. Und hinterher kann das dann als Slideshow wiedergegeben werden. Bei dem Ganzen werden immer nur Parameter gespeichert und keine richtigen Filme aufgenommen! Das ist mir wichtig, um keinen unnötigen Platz zu verschwenden.

"Du musst nicht warten, bis ich mit einer Aufgabe fertig bin, um weiter arbeiten zu können!"
Das verstehe ich unter Performance einer Software!
Einen Algorithmus empfindet man doch nur dann als zu langsam, wenn man nicht eher weiter arbeiten kann, bis er durchgelaufen ist. Bei Jessica sollen bei langwierigen Operationen Previews und Platzhalter existieren, mit denen man aktiv weiter arbeiten kann, als wäre der Prozess schon abgeschlossen. Man stelle sich langwierige Kopieroperationen oder Dateimodifikationen vor. Sowas dauert eben lange. Aber es steht ja vorher fest, wie das Resultat aussehen soll. Nur die Durchführung dauert seine Zeit.
Was sicher auch langwierig sein kann, ist die Durchführung der Smartalben.
Wird die Software während eines langwierigen Prozesses geschlossen, wird beim nächsten Start fortgesetzt. So, wie das Picasa auch bei der Gesichtserkennung macht.

"Ich kann auch Dinge rückgängig machen!"
Es soll so etwas wie eine Undo-Funktion geben. Z.B., wenn man Bilder versehentlich ins falsche Album gezogen hat, soll man das wieder rückgängig machen können.

"Ich hinterlasse einen menschlichen Eindruck!"
Das Ziel soll es sein, sich dem Benutzer menschlich mitzuteilen. Das soll erreicht werden, indem weitgehend technische Begriffe vermieden werden. Sämtliche Mitteilungen sollen leger und ungezwungen wirken.

"Und noch einige Kleinigkeiten ..."
Videos sollen ebenso wie Bilder zu verwalten sein. Bei gif-Bildern sollte man die Animation abspielen können. (Auch keine Selbstverständlichkeit bei den ganze Programmen, die es da so gibt.)

Herausforderungen und mögliche Schwierigkeiten
Wie schon erwähnt, handelt es sich bei dem "Big Picture" nur um eine sehr grobe Vorstellung von der endgültigen Software. Die meisten Dinge werden sich inkrementell entwickeln. Wenn dann so das typische Empfinden kommt, wie "Cool wäre es, wenn [...] möglich wäre.", dann werde ich überlegen, dies einzubauen.
Eine Herausforderung werden sicher die ganzen grafischen Spielereien und insgesamt das User Interface werden. Aber ich vertraue hier mal voll und ganz auf die Möglichkeiten der WPF:

Das Longterm-Goal wird sein, dass ich beim User-Interface keinerlei Logik-Code in der Codebehind-Datei habe. Es soll ja am Ende alles strikt nach MVVM ausgerichtet sein.

Schwierigkeiten könnte ich mir bei den Smartalben vorstellen und bei der ganzen Tagging-Problematik.
Ich werde womöglich auch keine typische Datenbank als Backend verwenden, da ich hier starke Performance-Probleme durch die Abfragen erwarte. (Es käme für mich, wenn überhaupt eine konventionelle Datenbank verwendet werden würde, nur SQLite in Frage, da man hier nix vorher installieren muss.)
Nein, ich werde mir selber ein System ausdenken, was für die Anforderungen genau zugeschnitten ist.

Der erste Schritt
... fängt erstmal klein an, um überhaupt eine Basis zu schaffen.
Am Anfang soll es möglich sein, einen (oder mehrere) Ordner mit Bildern zu wählen, welcher beim nächsten Programmstart automatisch geladen wird. Die erfassten Bilder sollen auch schon mal in einer Liste dargestellt werden. (Thumbnails werden zunächst noch nicht gespeichert. Die Bilder werden erstmal direkt geladen.)
Bei dem Schritt versuche ich auch schon ein bisschen das UI so halbwegs zu designen. (Von den Farben her und eventuell auch die Schriftart und Größe. Geplant ist auch ein sehr dezentes Hintergrundbild: http://fav.me/d2e1eo8. Dieses würde ich mit Inkscape "abpausen", um schärfere Konturen zu haben. Mit der Erlaubnis des Urhebers würde ich das dann in meine Software einbauen. ;-))

Probleme sehe ich hier eventuell bei dem Darstellen der Bilder. Ich habe da noch keine Vorstellung, wie die WPF mit sehr vielen Bildern intern umgeht. Unter Windows Forms hätte ich jedes Bild einfach manuell ausgelesen, direkt auf eine Oberfläche gezeichnet und das Bild dann wieder freigegeben.
Hier wird sich sowieso die Frage stellen, ob ich mein eigenes Steuerelement erzeuge, oder ein UserControl in Verbindung mit dem Image-Element besser ist.

Nun ja, das muss ich dann mal sehen.

Als nächstes käme dann die Vorbereitung des Projekts ...

Die Aufwärmphase vor der Projektvorstellung

noreply@blogger.com (Anonymous) — Mon, 16 Jan 2012 23:03:00 +0000

Eigentlich hatte ich zwar im letzten Beitrag versprochen, dass ich als nächstes das erste Projekt vorstellen werde. Aber ich wollte erstmal noch meine Vorgehensweise bei allen kommenden Projekten erklären.

Mir kommt es ja auf Konsistenz an, die ich bei allen Projekten anstrebe.

Die Vorstellung der Projekte

Jedes Projekt wird nach folgendem Schema vorgestellt werden:

The Big Picture
Unter dieser Überschrift werde ich meine Vorstellung von der zu entwickelnden Software präsentieren. Was soll sie am Ende mindestens können? Was sind meine persönlichen "must-have"-Features? Es wird eben ein grober Überblick gegeben, um Appetit zu wecken. ;-)
Herausforderungen und mögliche Schwierigkeiten
Jedes Projekt wird das ein oder andere Feature enthalten, was ich so noch nie zuvor implementiert habe. Das könnte also Schwierigkeiten machen oder eben sehr knifflig sein. Diese möglichen Stolpersteine werde ich hier aufzählen.
Der erste Schritt
Jedes Projekt fängt erstmal klein an. Daher definiere ich unter diesem Punkt die Features der ersten Iteration.

Gemeinsamkeiten aller Projekte

Sie tragen einen weiblichen Name. (Die Erklärung, weshalb das so ist, habe ich ja schon im letzten Beitrag geschrieben.)
Die Root-Bezeichnung meiner Namespaces wird entweder die Initialen CGO oder SachsenCoder tragen.

Ich tendiere aber zu SachsenCoder. Das erscheint mir weltweit eindeutiger zu sein.
Die Projekte werde ich bei github veröffentlichen. (Hoffentlich klappt das auch alles so. Ich habe bisher nur lokale Git-Repositories verwendet. *g*)
Innerhalb der github-Umgebung werde ich primär alle Texte auf Englisch verfassen. Das macht sich besser, falls doch mal jemand an dem Projekt mitmachen will. So ist es dann wenigstens international verständlich. (Auch, wenn mein Englisch sicher nicht ganz so erstklassig ist. *g*)
Alle Projekte werden als Basis .NET-Framework 4.0 verwenden.
Die Sprache selber wird C# sein. (Das ist die einzige Sprache, dessen Syntax mir wirklich gut gefällt!)
Alle Projekte werden im AppKata-Stil aufgezogen und nach der Spinning-Strategie angegangen. Das heißt, es gibt viele überschaubare Iterationen auf den Weg zum Big Picture und darüber hinaus. Jede Iteration soll einen kleinen, aber echten Nutzen hervorbringen. Jede Iteration wird je nach Komplexität in unterschiedlich kleine Slices aufgeteilt, damit ich/man von den Anforderungen nicht gleich erschlagen wird und ein Problem zeitnah gelöst werden kann.
Ich halte dieses Vorgehen für unerlässlich, um die Motivation aufrecht zu halten.
Spätestens nach jeder Iteration (oder dem ein oder anderen Slice) werde ich öffentlich darüber reflektieren, wie es gelaufen ist. Stellten sich die voraussichtlichen Schwierigkeiten wirklich als Hürde heraus? Wenn ja, warum? Wenn nein, warum nicht? Ist die Motivation noch gegeben oder steuere ich auf eine Lustlosigkeit zu? Bin ich mit der entwickelten Lösung zu Frieden? Entspricht sie den gegebenen Anforderungen? Gibt es Möglichkeiten der Verbesserung? Kann ich diese Verbesserungen umsetzen oder komme ich da an eine Know-How-Barriere?
Diese Art der Reflektion soll mir dabei helfen, die Sachen, die ich da entwickelt habe, nochmal bewusst zu machen. Es soll auch verhindern, dass ich in eine "Frickel"-Ebene abdrifte.
Die Entwicklung wird weitgehend gebloggt werden. Das heißt, die Lösungsfindung mache ich quasi öffentlich. So, als wenn ich laut denke oder jemanden meinen Lösungsweg erkläre. (Sicher werden mir dabei auch selber eventuelle Denkfehler auffallen.) Zudem gibt es anderen die Möglichkeit, die Entwicklung von Anfang an nachzuvollziehen. (Kann ja sein, dass am Ende wirklich geile Tools dabei rauskommen. Dann ist es doch fantastisch, wenn gerade sowas verständlich dokumentiert ist. Das ist ja im Open-Source-Bereich nicht selbstverständlich.)

Unter'm Strich soll die Entwicklung einen professionellen Charakter bekommen.

Endlich mal was auf die Beine stellen!

noreply@blogger.com (Anonymous) — Sun, 15 Jan 2012 23:31:00 +0000

Mit der Überschrift möchte ich mir selbst einen mentalen Arschtritt verpassen. Es ist ja nun schon fast ein Jahr her, als ich meinen letzten Blog-Post veröffentlicht habe. Und so kann ich nicht gleich mit der Tür ins Haus fallen, sondern muss erstmal den Leser auf das Kommende einstimmen.

Eigentlich habe ich noch viele Blog-Post-Entwürfe rumliegen, die alle davon handeln sollten, dass die Event-Based-Components doch nicht so prickelnd sind, wie man sie sich vorstellt.
Die Ironie daran ist eigentlich die, dass mir kaum ein ernsthafter Kritikpunkt einfallen wollte. Die einzige ernsthafte Kritik, die mir eingefallen ist, ist die schlechtere Code-Navigierbarkeit innerhalb von Visual Studio. (Z.B. beim Debuggen. "Gehe zu Definition" wird da nicht so schön funktionieren.)
Auch sollte man bei den EBC stehts eine visuelle Abbildung synchron zum Code mitführen. Da ist eben etwas Disziplin gefragt.

Und das war es eigentlich auch schon. Alles andere sind eher gravierende Vorteile gegenüber den herkömmlichen Praktiken, die so in aller Munde sind. (Wenn man ehrlich zu sich selber ist, merkt man das auch.)
Ich stellte das bei meiner "Micro-Pattern-Trilogie" auch fest. Man konnte alles schön voneinander getrennt halten. Aber sie waren zu schwergewichtig und brachten zu viel Rauschen mit. Damit war das Ding für mich gestorben.

Nun hat sich in der Zeit aber sehr viel getan. Die EBC sind sehr schlank, flexibel und aussagekräftiger geworden. EBC sind nun viel mehr ein Implementationsdetail. Der eigentliche Überbegriff für das Ganze heißt nun ganz einfach "Flow-Design". Es ist einfach ein Paradigma, wie man ein Business-Problem ganz einfach angehen kann. Wie das am Ende in der Programmiersprache XYZ umgesetzt wird, spielt keine Rolle. Die Art, wie es am schönsten in C# umgesetzt werden kann, ist eben das, was sich EBC nennt. (Wobei das eigentlich keinen extra Name bräuchte. Zumal ja die heutigen EBC kaum noch was mit der Ursprungsdefinition zu tun haben.)

Hierfür möchte ich noch zwei hervorragende Videos zu der neuen und erfrischenden Art der "Flow-Based"-Entwicklung vorstellen.

Das erste Video hatte ich damals live mitverfolgt. Das fand ich besonders motivierend, weil die alte EBC-Denke dort quasi gar nicht mehr auftaucht. Das zeigt sich besonders darin, dass es in der normalen Form keine Substantive mehr gibt. Es gibt also keine "Täter" mehr, wie z.B. einen "UserRegistrator" oder ähnliche abenteuerliche Gebilde, wo man letztlich nicht weiß, was er alles tut.
Stattdessen gibt es "Tätigkeiten", also echte "Funktionseinheiten". Eine Funktionseinheit könnte z.B. "Register_User" heißen. So benennt man dann z.B. auch die Klasse. Das ist das, was mir an dem neuen Konzept am Besten gefällt! Benennt man eine Klasse nach ihrer Funktion in der Verbform, ist definitiv klar, was sie tut. Im besten Fall tut sie nur diese eine Sache! Bei einem "UserRegistrator" weiß man leider nicht genau, was er alles tut. Da steckt die Funktionalität in einzelnen Methoden, welche eventuell weitreichende Abhängigkeiten haben, die gar nix mehr mit dem eigentlichen Kontext zu tun haben. Und das verleitet dazu, dass man Verantwortlichkeiten mischt.

Das zweite Video zeigt quasi an einem praktischen Anwendungsfall, wie der Entwicklungsprozess mit "Flow-Design" aussieht. Hier kommt auch gut zur Geltung, dass ein "Flow-Design" wunderbar evolviert.

Soviel erstmal zu der kleinen Einführung.
Um zum Ausgangspunkt zurückzukommen: Ich muss (und will) endlich mal ein privates Projekt auf die Beine stellen! Unter Zuhilfenahme von "Flow-Design".

Projektideen habe ich da mehr als genug:

Ein Bildverwaltungsprogramm
Das soll so in die Richtung wie Picasa oder die Windows Live Fotogalerie gehen. Aber mein Programm soll flexiblere und besser anpassbare Slideshows ermöglichen. Auch soll es mit sehr vielen Dateien mühelos umgehen können. (Das ist nicht immer selbstverständlich bei den Lösungen, die es da so gibt.) Aber das eigentliche Killerfeature sollen ja Smartalben sein! Die vermisse ich nach wie vor in Picasa und bei der Windows Live Fotogalerie. (Der Photoshop Elements Organizer bietet zwar Smartalben an, aber die kann man nicht schachteln.) Generell sollen alle erdenklichen Filtermöglichkeiten möglich sein ... beliebig komplex. Was die Software in erster Linie nicht bieten soll, sind diverse Social-Features und Bildbearbeitungsfunktionen. Gesichtserkennung ist auch erstmal nicht geplant. (Das sind aber Sachen, die per Flow-Design leicht nachrüstbar sein sollten.) Die Verwaltungsaspekte sollen hier im Vordergrund stehen.
Einen Editor und Player für interaktive Stories
Sowas finde ich einfach "nice to have". ;-)
Ich stelle mir das so vor, dass man einfach beginnt, eine Geschichte zu schreiben. Und während dieses Vorgangs kann man dann intuitiv die dynamischen Aspekte der Storie festlegen. (Charaktere, Handlung, Interaktion, etc.) Man soll nicht schon vorher wissen müssen, was man alles braucht oder was dynamisch werden soll, wenn man eine solche Geschichte beginnt. Ein Tool, was so in die Richtung geht, aber in meinen Augen noch nicht so richtig den Punkt getroffen hat, ist z.B. Twine. Das fühlt sich noch zu sehr nach Scripting an. Und übersichtlich ist das bei komplexeren Stories auch nicht gerade. Oder wenn noch Variablen ins Spiel kommen. Oder wenn man seine Charaktere im Blick behalten will, etc.
Ein Tool für einfachere Softwareentwicklung
Davon träumt sicher jeder Softwareentwickler! ;-D
Ehe ich da viel dazu erzähle ... ich denke da an eine Mischung aus Code Bubbles und FlowStone. Quasi ein Softwaremodellierungstool.
Eine Wuala-Alternative
Denn Wuala unterstützt ja keinen Speichertausch mehr. :-(
Ein Automatisierungstool
Ja, sowas Ähnliches wie FinalBuilder. Nur nicht so Feature-Complete und universell wie dieses Tool derzeit zu sein scheint. Einfach ein Tooling, was meine kleinen Automatisierungsanforderungen komfortabel erfüllt. (Ein bisschen Templating, d.h. Platzhalter durch echte Werte ersetzen; Dateiverwaltungskram; Commandline-Tools ausführen; etc.) Das Tool könnte "nebenbei" entstehen. Je nachdem, welche Automatisierung ich gerade gebrauchen könnte.

Tja, an Ideen mangelt es nicht. Ich will aber realistisch sein: Das Softwareentwicklungstool und die Wuala-Alternative wird es voraussichtlich nicht (sofort?) geben. Das entwickelt man auch mit Flow-Design nicht mal eben so in der knappen Freizeit.

Bei den anderen Programmen sehe ich da aber schon realistische Ziele.

Was alle Programme (hoffentlich) gemeinsam haben werden, ist Folgendes:

Ein modernes, einfach zu handhabendes (G)UI. Heutzutage muss man wirklich keine hässlichen GUIs mehr hinnehmen oder einem User anbieten. Die Tools für Mac OS sehen immer so stylisch aus. Warum sollte das nur Mac OS exklusiv sein?
Jedes Tool versuche ich penibel im Flow-Design-Stil zu entwickeln. Also erst der grafische Entwurf und dann der Code. (Das wird für mich eine disziplinarische Herausforderung werden, weil ich sonst alles gleich im Code entworfen habe.) Als Tool für die Diagramme werde ich hier yEd verwenden.
Sie werden frei wie "Freibier" und sicher auch frei wie "frei veränderbar" sein. ;-)
Ich verfolge kein finanzielles Interesse. Die Tools entwerfe ich, weil ich sie sehnlichst brauche. Ich will nicht länger warten, bis sie mal irgendjemand irgendwann programmiert. Und warum sollte ich die Tools am Ende nicht anderen zur Verfügung stellen?

Was erwarte ich von dem Vorhaben?

In erster Linie, wie bereits erwähnt, brauche ich die Tools, weil mir die existierenden Lösungen nicht das bieten, was ich wirklich brauche. (Oder weil andere Lösungen zu komplex und/oder zu teuer sind.)
Ich will meine Fähigkeiten als Entwickler ausbauen, sodass mir die Flow-Design-Methodik in Fleisch und Blut übergeht. Ich möchte nicht mehr in die alte OOP-Denke verfallen.
Kann es für den Arbeitsmarkt bessere Referenzen geben, als selbst entwickelte Software inklusive Dokumentation von deren Entstehungsprozess?
Ich möchte eben auch einfach mal in der Freizeit etwas Produktives machen. Bisher bin ich nur auf Arbeit wirklich produktiv und entwerfe Software. Aber da hat man eben immer den Zeitdruck; muss die Anforderungen so umsetzen, wie sie gefordert sind und die resultierenden Tools bringen einem selbst keinen Nutzen. Es ist eben irgendwie einfach nur Arbeit, die man macht. (Es macht zwar trotzdem Spaß, aber so richtig kann man sich irgendwie nicht entfalten.) Ich will einfach auch mal selber die Anforderungen definieren und Tools entwickeln, die mir persönlich sehr viel bringen. Und das ohne BWLer im Rücken, aus deren Sicht es ja keine Probleme gibt und alles "straight forward" ist. Ohne BWLer, für die Softwareentwicklung nur ein notwendiges, unberechenbares Übel in der Kostenkalkulation ist.
Das Flow-Design verspricht eigentlich echte Wiederverwendbarkeit, da es nur Input- und Outputabhängigkeiten gibt. Ich hoffe, dass ich da auch viele Funktionseinheiten in anderen Projekten verwenden kann.

Was sind die persönlichen Herausforderungen und Risiken für mein Vorhaben?

Durchhaltevermögen! Das ist definitiv die größte Herausforderung der ich mich stellen muss. Ich weiß schon jetzt, dass es sicher Phasen geben wird, wo ich mal definitiv keinen Bock haben werde, irgendwas zu programmieren. Ich denke, das ist aber ganz natürlich. Man ist schließlich kein Roboter. Ich hoffe nur, dass solch eine Phase nicht dauerhaft eines meiner Vorhaben zerstört!
Durch meine hohen Anforderungen an die Usability werde ich endlich mal gezwungen, mich mit Drag & Drop, (dynamischen) Kontextmenüs und sonstigen GUI-Spielereien auseinanderzusetzen. Auch, was die prinzipielle Gestaltung der Oberfläche anbelangt. Da muss ich selber hartnäckig bleiben und darf mich nicht zu schnell mit einer ungewollten Lösung abfinden. Daher muss ich vorher penibel meine exakte Vorstellung dokumentieren und mich dran halten.
Ich muss mir einheitliche Konventionen schaffen und mich penibel dran halten! Auf Arbeit ertappe ich mich oft, dass ich mit diesem Grundsatz breche. Oft aus Bequemlichkeit oder Zeitdruck.

Was gibt es sonst noch zu wissen?

Ein Framework zu benutzen, ist für mich ein notwendiges Übel, um schnell Resultate zu bekommen. Für mich gibt es im Entwicklungsprozess aber nix Schlimmeres, als vor Problemen zu stehen, die mit dem Framework zu tun haben. Die Probleme entstehen, weil man oft nicht genau weiß, wie man ein Framework richtig benutzt. Oder man steht vor einem merkwürdigen Verhalten, was man nicht versteht und nicht nachvollziehen kann. (Das ist die Bug- und Fehlerquelle Nummer eins.) Daher meide ich auch den exzessiven Gebrauch von Framework-Features, die ich nicht verstehe oder nachvollziehen kann. Da erfinde ich das Rad lieber neu und weiß dann wenigstens, wie es funktioniert. Das werde ich auch bei meinen Projekten so handhaben. Mit der Strategie bin ich bisher sehr gut gefahren. (Außerdem ist es DAS, was mir überhaupt am Programmieren gefällt: Wenn man mal selber etwas implementieren kann und es hinterher noch tadellos funktioniert.)
Ich werde nach Möglichkeit offene Libraries für Programmteile verwenden, wo ich selber einfach nicht die Zeit oder das nötige Know-How habe, um eine solche Funktionalität selber zu implementieren. (Z.B. Gesichtserkennung oder sowas.)
Um meine grafischen Fähigkeiten etwas zu schulen, werde ich mich dieser Quelle bedienen: http://2dgameartforprogrammers.blogspot.com/
Da dreht sich zwar alles um Spielegrafik, aber gerade was die Shading-Grundlagen anbelangt, kann man das Wissen sicher auch universell für GUIs einsetzen.
Die Codenamen meiner Projekte werden weibliche Vornamen tragen!
Ich habe lange überlegt, wie ich meine Projekte nennen könnte. Zuerst dachte ich an Tierbezeichnungen. Aber fast jede Software trägt ja irgendwie eine Tierbezeichnung als Codename. (Ubuntu & Co. lässt grüßen. *g*)
Davon will ich mich abgrenzen. Software ist in meinen Augen in jeder Hinsicht weiblich und nicht tierisch! ;-) Und vor allem möchte ich Namen für meine Software haben, die man sich auch gut merken und aussprechen kann. (Schließlich werden diese Namen ein Bestandteil des Namespaces. Da möchte ich keine cryptischen Bezeichnungen drin haben. *g*)

Im nächsten Beitrag werde ich dann sicher mein erstes Projekt vorstellen. Da bin ich selber sogar schon ganz gespannt drauf. :-D

Welches Paradigma passt zu Dir?

noreply@blogger.com (Anonymous) — Mon, 07 Feb 2011 22:57:00 +0000

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?

noreply@blogger.com (Anonymous) — Sat, 05 Feb 2011 22:49:00 +0000

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!

noreply@blogger.com (Anonymous) — Sat, 10 Jul 2010 22:13:00 +0000

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!

noreply@blogger.com (Anonymous) — Mon, 31 May 2010 20:24:00 +0000

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!

noreply@blogger.com (Anonymous) — Tue, 11 May 2010 21:30:00 +0000

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

noreply@blogger.com (Anonymous) — Tue, 11 May 2010 19:16:00 +0000

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 ...

noreply@blogger.com (Anonymous) — Mon, 10 May 2010 21:30:00 +0000

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! :-)

Das Rad neu erfinden? Nein!

noreply@blogger.com (Anonymous) — Sat, 08 May 2010 21:16:00 +0000

Heute Früh, zwischen 2 und 3 Uhr bin ich plötzlich aufgewacht und konnte nicht mehr einschlafen. Ohne Witz!
Mir gingen die ganze Zeit Ideen für weitere Features meiner begonnenen "Atomix" Anwendung durch den Kopf. Sind die Ideen mit dem MPT Konzept umsetzbar? Die Gedankenexperimente gingen los und ich kam immer zu dem selben Ergebnis: Natürlich ist das umsetzbar! Unter Zuhilfenahme der MPT ist das sogar sehr einfach, da man sich ja keine Gedanken über die Objektabhängigkeiten machen muss. Man geht ja bei der Implementation einfach davon aus, dass man die benötigten Daten einfach von irgendwoher bekommt. Und dann nutzt man einfach diese Daten für sein gewünschtes Feature.
Früher habe ich mir eher den Kopf darüber zerbrochen, wie ich die Objekte am Besten miteinander verkopple, um zu dem gewünschten Feature zu kommen:

Injiziere ich Objekt "A" in Objekt "B", oder doch besser Objekt "B" in Objekt "A"? Und was ist, wenn ich in Objekt "A" nur einen Teil der Daten von Objekt "B" benötige? Vielleicht benötige ich nur einen bestimmten String von Objekt "B"? Weshalb also Objekt "A" vom kompletten Objekt "B" abhängig machen? Ich kann es aber auch nicht anders machen, weil ich z.B. den String irgendwann dynamisch zur Laufzeit benötige. Also muss ich es doch so machen.
Und wenn ich in Objekt "B" noch mit Objekt "A" hantieren will? [usw. usf.]

Diese Überlegungen entfallen bei der MPT völlig, da hier im Grunde alle Objekte auf der selben Ebene stehen. Und kein Objekt interessiert sich dafür, wo es seine Daten herbekommt oder wo seine eigenen Daten hingehen. Man benötigt eine bestimmte Datenstruktur für Irgendwas Bestimmtes? Passende Schnittstelle dafür implementieren und seine Idee fortsetzen.

Dadurch sind massenhaft Features durch meinen Kopf gegangen. Das hat kaum ein Ende genommen. Echt schlimm, wenn man dabei durch nix gebremst wird ... höchstens seine eigene Fantasie. Und ehe ich mich versah, ging schon wieder die Sonne auf. *g*

Aber dennoch kam ich an einen Punkt, der mich heute den ganzen Tag stark beschäftigt hat:
"Atomix" wird auch Quellcode parsen müssen! Soll ich da anfangen, einen eigenen Parser zu entwickeln oder eine existierende Lösung suchen?

Ich dachte tatsächlich erst daran, einen eigenen Parser zu entwickeln. Schnell mal nach der offiziellen C# Spezifikation gegoogelt und den Standard ECMA-334 gefunden. "Rein geguckt und zam gezuckt!", wie es so schön heißt. ^_^
Dass C# komplex ist, ist klar. Aber dieses Dokument hat es schon in sich. Eben eine richtige Spezifikation.

Ich hielt dennoch an dem Gedanke fest, einen eigenen Parser zu entwickeln. Aber mir fehlte ein bisschen der konkrete Ansatz, wie man sowas programmiert. Also nochmal gegoogelt und ich fand das: "Writing a parser: overview".

Nun war die dort erfundene Beispielsprache ja recht einfach. Einfacher, als etwa C#. Und dennoch ist der Parser für jene einfache Sprache so komplex. Wie würde der erst bei C# aussehen? So einen Parser hat man jedenfalls nicht mal so eben nebenbei programmiert.

Nun will ich ja im Grunde nur ein RAD-Tool entwickeln, welches mir ein bisschen Arbeit abnehmen soll. Und der dafür benötigte Parser ist da eher ein notwendiges Übel. Der soll bei der Entwicklung nicht mehr Aufmerksamkeit bekommen, als meine eigentliche Anwendung.
So kommen wir wieder auf die Überschrift dieses Beitrages zurück. Ist es notwendig, das Rad neu zu erfinden? Also in dem Falle, sicher nicht! Ich kenne mindestens ein Projekt, welches einen Parser verwendet, wie ich ihn benötige: "SharpDevelop".
Ich lud mir den Sourcecode von SharpDevelop runter und stöberte darin nach etwas, was "Parser" hieß. Ich hatte auch etwas gefunden, aber es war nicht direkt das, was ich erwartet hatte.
Also googelte ich nochmal, weil ich wissen wollte, wie man den Parser von SharpDevelop für eigene Projekte nutzen kann. Tatsächlich fand ich auch etwas: "NRefactory".
Das sieht sehr vielversprechend aus und scheint einfach verwendbar zu sein. (Und wenn man einmal weiß, wonach man suchen muss, findet man es auch gleich im Quellcode von SharpDevelop wieder. *g*)
Ich fand auch noch eine Auflistung von verschiedenen Parsern bei Google: "Parser for C#".

Hmmm, dort fiel mir auch die "Common Compiler Infrastructure: Metadata API" ins Auge. Das werde ich mir vielleicht auch mal näher ansehen.
Aber theoretisch dürfte für meine Zwecke die normale "System.Reflection" ausreichen. Mal gucken.

Tja, nun hätte sich im Grunde die Sache mit dem Parser erledigt und ich kann mich wieder voll und ganz auf meine eigentliche Anwendung konzentrieren. :-)

Was gibt es Neues?

noreply@blogger.com (Anonymous) — Wed, 05 May 2010 21:57:00 +0000

Zunächst mal: Keine Angst! Das MPT-Beispiel ist nicht in Vergessenheit geraten. Es muss jedoch erstmal etwas warten. (Warum, erkläre ich weiter unten.)

Auf Arbeit habe ich momentan die Zeit, meine Softwareprojekte aufzuräumen. (Das heißt, ich nehme mir die Zeit einfach, wenn sonst nix zu tun ist. *g*) Und da dachte ich mir so, dass ich mein letztes (noch aktuelles) Projekt restrukturiere. Gerade, weil ich weiß, dass da später noch mehr Features implementiert werden sollen. Und bei der alten Struktur wäre das "Frickeln" vorprogrammiert. ;-)

Also entschied ich mich, die eher frickelhafte (aber funktionale) Software in eine ordentliche MPT umzuformen. Ganz einfach ist das nicht, da in der alten Struktur viele verschiedene Aspekte in einer einzigen Klasse zusammengefasst sind. Das Meiste von der Business-Logik sammelte sich leider in der GUI-Klasse an. (Wenn es schnell gehen soll und man noch den Überblick behält, kann man schon mal diesen Schritt wählen. Denn Merke: Der Kunde interessiert sich am Ende nur für das Tool und nicht über dessen interne Struktur. There is no perfect Design!)
Aber man tut sich selber einen großen Gefallen, wenn man die Aspekte seiner Software voneinander trennt!
Tja, was soll ich sagen? Ich freue mich immer wieder, dass das MPT Konzept tatsächlich so funktioniert, wie ich es mir gedacht habe. Nebenbei entdecke ich Möglichkeiten, wie ich es noch optimieren kann, um mir etwas Arbeit abzunehmen und den Überblick zu behalten.

Dabei kommen wir gleich zum nächsten Punkt: Es muss leichter fallen, Software mit dem MPT Konzept zu erstellen!

Dafür muss unbedingt ein RAD-Tool her! Da es sowas für die MPT noch nicht gibt, ist mein Einsatz gefragt. *g*
Vergangenes Wochenende hatte ich schon mit der Entwicklung begonnen. Der Projektname lautet "Atomix". (Der Name hat sich so ergeben, weil man mit dem Tool seine Software so erstellt, wie wenn man einzelne Atome miteinander verbindet.) Ich möchte mal kurz erklären, wie ich mir dieses Tool vorstelle:
Es soll von Anfang an mit dem MPT Konzept entwickelt werden. Ich möchte es so zeitig wie möglich produktiv einsetzen können. Das heißt also, die Features haben Vorrang und das Design kommt später. Es soll schließlich in erster Linie ein Werkzeug sein und seinen Zweck erfüllen. (Das Design sollte sich aber später leicht aufpeppen lassen. Der völligen Entkopplung sei Dank! *g*)

Dieses Tool soll vorerst nicht die gewohnte Entwicklungsumgebung ersetzen, sondern diese ergänzen. (Aber nicht in Form eines Plug-Ins!)
Im Vordergrund steht die MPT-Struktur der zu entwickelnden Software. Aus diesem Grund wird diese in einer grafischen Form dargestellt werden. Wie man sich das ungefähr vorstellen kann, soll folgende Grafik zeigen:

So könnte die grafische Repräsentation mal aussehen.
(zum Vergrößern auf's Bild klicken)

Dieses Diagramm hatte ich mit yEd entworfen und zeigt den funktionalen Beginn meines ersten "Atomix"-Versuches. (Dies verfolge ich aber nicht weiter, weil ich mich hierbei noch zu sehr an der Idee des "Presenter First" orientiert hatte. Das heißt, hier haben die konkreten Objekte selber feste Abhängigkeiten. Man achte auf die zusammenhängenden weißen Objekte mit der dicken Linie. Das darf nicht sein, da es ein Stilbruch bei der MPT ist.)

Was man aber gerade an diesem Diagramm sehr gut sehen kann, ist die organische Form, welche die Software letztlich hat. Sie ist nicht starr und steif, sondern anpassbar und flexibel.

Bei meinem Tool steht also die Grafik im Mittelpunkt. Wenn man dann z.B. auf eines der Elemente klickt, soll ein Fenster aufpoppen, wo der zugehörige Quellcode drin steht. Dazu inspiriert hat mich der neue Ansatz der sogenannten "Code Bubbles".
Man soll dann nur den Quellcode sehen, der in dem Moment wirklich relevant ist.
Hinzufügen von neuen Triplets soll mit wenigen Mausklicks möglich sein. Dabei soll sich stehts der Quellcode automatisch mit anpassen. Die Grafik soll sich auch aktualisieren, wenn ich z.B. in Visual Studio den Quelltext ändere.
Die einzelnen Elemente sollen durch einfaches Drag & Drop austauschbar sein, sodass man seine Software im Grunde durch wenige Klicks verändern kann.

Das sollen erstmal die groben Ideen sein, die mir spontan eingefallen sind.
Aber alles schön der Reihe nach. *g*

Naja, und dafür muss erstmal die Fortsetzung von meinem MPT Beispiel etwas zurückstehen.

1. MPT Beispiel - Teil 1

noreply@blogger.com (Anonymous) — Sat, 24 Apr 2010 16:47:00 +0000

So, jetzt gibt es das erste praktische Beispiel zur Micro-Pattern-Trilogie.
Ich hatte gründlich darüber nachgedacht, ob ich extra für jedes Triplet eine eigene kleine Anwendung entwickeln soll, oder nicht. Aber ich dachte mir so, für das CML Triplet lohnt sich keine eigenständige Anwendung, weil es schlicht zu primitiv ist.
Ich hatte da aber schon mal etwas probiert, was vom Umfang her einem realistischen Beispiel würdig ist. Da kommt im Prinzip alles vor, außer des CPS Triplets. (Das ist aber nicht schlimm. Das kommt dann einfach ein anderes Mal dran.)
Weil Bilder bekanntlich mehr sagen, als tausend Worte, stelle ich die Anwendung einfach mal in einem kurzen Video vor:

(Oh Gott! Da kommt man sich teilweise blöd vor, wenn man mit 'nem Mikrofon spricht. Naja, ich bin nicht so der Rede-Mensch. Aber irgendwie fetzt das trotzdem! Ich werde sicher noch mehr Videos dieser Art machen. Aber da wird dann etwas mehr los sein, als in diesem Video. *g*)

Ja, wie du gesehen hast, wird es dynamisch. Das heißt, es werden zur Laufzeit neue Ansichten erzeugt, wobei jede einzelne Ansicht mithilfe des TFR Triplets den aktuell eingegebenen Text erhält. Außerdem - und das war damals im Prinzip der eigentliche Grund für dieses kleine Programm - bekommt das Hauptformular die verschiedenen Ansichten auf die selbe Weise.

Ich würde sagen, wir fangen mit dem einfachsten Teil der Software an. Das wäre in diesem Fall die Benutzeroberfläche, bzw. dessen Innenleben ... also der Quellcode.

using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;

namespace PFDynamic
{
 public partial class Form1 :
  Form,
  IAmTextTransmitter,
  IAmAddTextViewCaller,
  IAmTextViewReceiver
 {
  public Form1()
  {
   InitializeComponent();
  }

  public event EventHandler SendText;

  public string ReturnText()
  {
   return textBox1.Text;
  }

  private void textBox1_TextChanged(object sender, EventArgs e)
  {
   Say.Carefully(SendText, this);
  }

  private void button1_Click(object sender, EventArgs e)
  {
   Say.Carefully(AddTextView, this);
  }

  public event EventHandler AddTextView;

  public void ReceiveTextView(IAmTextView textView)
  {
   this.Controls.Add(textView.Control);
   Say.Carefully(SendText, this);
  }
 }
}

Das ist wirklich alles! Mehr manueller Quellcode steckt nicht in der Form1-Klasse.
Ich werde das Listing nun einzeln erklären.

Zeige mir deine implementierten Schnittstellen und ich sage dir, wer du bist!
Diese Aussage ist wörtlich zu verstehen. Sehen wir uns dazu den Klassenkopf an:

public partial class Form1 :
  Form,
  IAmTextTransmitter,
  IAmAddTextViewCaller,
  IAmTextViewReceiver

Ich weiß an dieser Stelle exakt 4 Dinge von Form1. Zum Einen ist sie von der Basisklasse "Form" abgeleitet. Das ist aber nichts Besonderes.
Viel interessanter sind die Schnittstellen! Diese kann ich direkt so lesen, als wären sie eine "Personenbeschreibung" von Form1.
"IAmTextTransmitter" bedeutet: "Ich bin ein Text-Transmitter." Somit weiß ich, dass Form1 aktiv einen Text versendet.
"IAmAddTextViewCaller" bedeutet: "Ich bin ein AddTextView-Caller." Somit weiß ich, dass Form1 sagt, dass eine Textansicht hinzugefügt werden soll.
"IAmTextViewReceiver" bedeutet: "Ich bin ein TextView-Receiver." Somit weiß ich, dass Form1 passiv eine Textansicht empfängt.

Ohne den eigentlichen Quelltext gesehen zu haben, weiß ich in dem Moment sofort, welche Rolle die Form1 in dem Gesamtsystem spielt. Das geht aber eben nur, wenn hier keine Willkürlichkeit herrscht.
Sehen wir uns dazu die Schnittstellen selbst einmal an. (Alle Schnittstellen sind natürlich im Namespace "PFDynamic" enthalten. Ich habe das nur zur Übersichtlichkeit weggelassen.)

public interface IAmTextTransmitter
{
 event EventHandler SendText;
 string ReturnText();
}

Zufällig passt diese Schnittstelle exakt zu dem theoretischen Beispiel meiner TFR Triplet Erklärung. ;-)
Man sieht hier, dass die Schnittstelle ein Event "SendText" und eine Methode "ReturnText()" fordert. Mehr nicht.
Die anderen beiden Schnittstellen sind genauso übersichtlich und erklären sich quasi selber, weshalb ich da nichts dazu sage.

public interface IAmAddTextViewCaller
{
 event EventHandler AddTextView;
}

public interface IAmTextViewReceiver
{
 void ReceiveTextView(IAmTextView textView);
}

Aber man sieht hier, dass die Schnittstellen nur das Nötigste enthalten. In der Regel sind es nicht mehr, als zwei Elemente. Das ermöglicht es, einer Klasse mal schnell eine Schnittstelle zuzuweisen und diese zu implementieren.
Kommen wir zum nächsten Punkt!

Mit der Idee fängt alles an!
So banal das klingt, ist es aber auch! Es ist ein bisschen sowas, wie "Programming by Wishful Thinking". Allerdings mit der totalen Entkopplung der Objekte zueinander.
Bezogen auf diese kleine Anwendung, dachte ich mir Folgendes:
"Wenn ich auf einen Button klicke, soll eine Ansicht hinzugefügt werden. In einer TextBox möchte ich Text eingeben können, der automatisch bei allen anderen Ansichten aktualisiert wird. Zudem möchte ich jede Ansicht individuell entfernen können."

So klickte ich mir zunächst die Oberfläche zusammen. Einen Button und eine TextBox. Die Ansichten ließ ich logischerweise weg, weil die ja dynamisch hinzugefügt werden sollten.
Ich klickte doppelt auf den Button, weil ich ja das Klick-Event haben wollte. Und was wollte ich mit dem Klick erreichen? Richtig, ich wollte eine Text-Ansicht hinzufügen. So programmierte ich es dann auch:

private void button1_Click(object sender, EventArgs e)
{
 Say.Carefully(AddTextView, this);
}

Der Aufruf mit dem "Say Carefully" ist nur ein einfacher Wrapper, um mir Arbeit abzunehmen und die Lesbarkeit zu erhöhen. So sieht diese Wrapper-Klasse aus:

using System;

static class Say
{ 
 public static void Carefully(EventHandler statement, object caller)
 {
  if (statement != null)
   statement(caller, EventArgs.Empty);
 }

 public static void Carefully(EventHandler statement, object caller, EventArgs arguments)
 {
  if (statement != null)
   statement(caller, arguments);
 }
}

Diese Hilfsklasse verwende ich in allen MPT-Projekten. Das aber nur am Rande.
Wie man in dem Beispiel gesehen hat, formuliere ich bei dem Button-Klick im Grunde nur das, was ich damit erreichen will. Um das "WIE" habe ich mir in dem Moment noch keine Gedanken gemacht, weil dies nur die Gedanken blockieren würde. Durch den Button-Klick soll eine Ansicht hinzugefügt werden. Punkt! Mehr ist an dieser Stelle nicht wichtig. Dann hatte ich die jeweilige Caller-Schnittstelle dazu erstellt. (Siehe oben!)

Die nächste Sache: So wie ich Text in die TextBox eingebe oder verändere, soll dieser an alle Empfänger gesendet werden.
Also nahm ich hierfür einfach das "TextChanged" Ereignis der TextBox her:

private void textBox1_TextChanged(object sender, EventArgs e)
{
 Say.Carefully(SendText, this);
}

Das sollte sich auch wieder selbst erklären, denke ich. Das macht eben einen weiteren großen Vorteil aus, dass man den Quelltext nicht extra kommentieren braucht. Der Quellcode ist selbstredend. So sollte das IMHO auch sein. Wer Kommentare braucht, hat IMHO eine unsaubere Codebase und sollte an der Verständlichkeit seines Quellcodes arbeiten.

So, und wer Text sendet, muss diesen auch bereitstellen! Dafür gibt es ja diese Funktion:

public string ReturnText()
{
 return textBox1.Text;
}

Hier wird eben einfach der Text in der TextBox zurückgegeben. Einfacher geht es nicht.

Eine letzte Sache fehlt noch: Wir wollten ja auch Text-Views empfangen. Kommt also nun zum Schluss diese Möglichkeit hinzu:

public void ReceiveTextView(IAmTextView textView)
{
 this.Controls.Add(textView.Control);
 Say.Carefully(SendText, this);
}

Auch diese Methode kam quasi so zustande, wie ich sie gern verwenden wollte. Wir erinnern uns: Wir wollten alles nur über Schnittstellen abwickeln!
So wollte ich als Parameter eine Schnittstelle, die sich selber als "IAmTextView" bezeichnet. Und diese dient quasi als Wrapper für das "Control", welches ich ja in der ersten Anweisung der "Controls"-Liste der Form-Klasse hinzufüge. Sonst wäre dies nicht Bestandteil der Form und somit nicht sichtbar.
Danach möchte ich, dass nochmal der Text gesendet wird. Denn die neu hinzugefügten Ansichten sind ja praktisch noch jungfräulich ... also leer.

Das ist auch ein wichtiger Punkt! Ich hätte das Senden des Textes auch in das Button-Klick Event einfügen können, z.B. so:

private void button1_Click(object sender, EventArgs e)
{
 Say.Carefully(AddTextView, this);
 Say.Carefully(SendText, this);
}

Die Software hätte genauso funktioniert, da dies quasi serielle Funktionsaufrufe sind. Was wäre aber, wenn das Event "AddTextView" gar nicht bedient wird? Dann wird "SendText" umsonst aufgerufen, weil ja keine Ansicht hinzugefügt wurde und alle bestehenden Ansichten bereits aktualisiert sind. Ein unnötiger Funktionsaufruf, also. Bei diesem Beispiel fällt das ja nicht ins Gewicht. In der Praxis könnten hier aber komplexe Operationen dahinter stehen, was dann sehr wohl stören könnte.

Oder ein anderes Beispiel:
Nach dem Aufruf von "AddTextView" wird die Verarbeitung an einen Thread übergeben, wodurch die Funktion sofort wieder zurück kommt und das Event "SendText" aufruft. Der andere Thread ist aber noch dabei, die "TextView" zu generieren. (Das kann ja in der Praxis auch sehr komplex sein.) Nun wurde "SendText" aber schon ausgeführt, obwohl noch keine neue "TextView" erzeugt wurde. Kurze Zeit später ist der Thread soweit und wir bekommen die "TextView". Aber sie wird keine Daten enthalten, weil der Zug (SendText) schon abgefahren ist. Dumm gelaufen. (Aber keine Angst! Der Kunde wird sich schon über den Bug beschweren. *g*)

Daher sollte man sich immer folgende Frage stellen:
"Sind die Ereignisse abhängig oder unabhängig voneinander?"
Am besten versucht man sich dabei immer das Thread-Beispiel vorzustellen. Also das Szenario, dass die Events quasi parallel ausgeführt werden.
Sind es parallele Prozesse, kann man diese auch parallel aufrufen bzw. implementieren.
Müssen die Events seriell, also nacheinander ausgeführt werden, sollten diese auch so aufgerufen werden.

Das soll es soweit erstmal gewesen sein. Im zweiten Teil geht es dann weiter. (Ich schätze mal, dass ich dann die "Mittelmänner" zeige.)

Hypothese: "Die Micro-Pattern-Trilogie reicht völlig!"

noreply@blogger.com (Anonymous) — Sun, 18 Apr 2010 21:51:00 +0000

Ehe wir uns die praktische Anwendung der Micro-Pattern-Trilogie (kurz MPT) ansehen, möchte ich hier zunächst eine kühne Behauptung aufstellen:

"Ich behaupte, dass man nur unter Zuhilfenahme der MPT absolut jede denkbare Software realisieren kann, egal wie komplex diese ist!"

Ziemlich gewagt, diese Aussage, oder? Gerade, wenn man bedenkt, dass es schon andere helle Köpfe gab, die sich viele Entwurfsmuster ausgedacht haben, um den heutigen Softwareproblemen Herr zu werden.
Ich sage auch nicht, dass alle Muster sinnlos sind. Im Gegenteil!
Es gibt aber eben auch Muster, welche IMHO redundant sind. Zum Beispiel gibt es da einmal den "Model View Controller" und den "Model View Presenter". Beide erfüllen unter'm Strich die selbe Funktion: Das Eine soll vom Anderen getrennt sein und dennoch hängen alle drei Elemente zusammen. Beim MVC sieht man diesen Widerspruch sehr schön.
Warum machen sich die Entwickler also das Leben so schwer?
Vom MVC gibt es zig Modifikationen, sodass man nicht sagen kann: "Ach ja, MVC! Deine Software funktioniert also so und so!" Der andere guckt dich dann verdutzt an und sagt: "Ähm ... nee, meine MVC-Variante funktioniert so und so!" ... Ach so, verstehe ... oder auch nicht. Gut, dass wir drüber geredet haben. ;-P

Bei der MPT sieht es aber anders aus! Hier ist die Spezifikation total simpel und eindeutig. Wenn ich von einem Caller-Mediator-Listener Triplet (kurz CML) rede, dann funktioniert es auch genau SO und nicht anders. Hier wird es keine Abwandlungen geben! (Ein Wassermolekül besteht schließlich auch immer aus zwei Wasserstoffatomen und einem Sauerstoffatom. Und wenn man von Wasser redet, weiß jeder, was das ist.)

Wenn ich mir überlege, dass es zu diesen diversen Pattern ganze Bücher gibt, welche diese erklären ... OMG!
Und manche Pattern sind auch nicht gerade einfach zu verstehen. (Wie will man dann erst Quellcode verstehen, welcher mit so einem Pattern realisiert ist?)

Sicher, MPT ist auch ein Muster. Aber ein sehr Einfaches, was letztlich jeder Mensch nachvollziehen kann.
Die MPT besteht nur aus drei einfachen Triplets:

Die Vorteile überwiegen die Nachteile um ein Vielfaches:

Totale Entkopplung der einzelnen Objekte!

Kein Objekt weiß von der Existenz eines anderen Objekts. Die einzelnen Objekte dürfen auch gar nichts voneinander wissen, geschweige denn direkt miteinander kommunizieren. Dies würde unweigerlich zu einer chaotischen Programmstruktur führen. Theoretisch sollte jedes Objekt völlig ohne Konstruktor-Argumente auskommen. Was ein Objekt benötigt, kommuniziert es einfach "ins Blaue" hinein. Irgendjemand wird "ihm" schon geben, was "er" verlangt (siehe CPS). Woher "er" es letztlich hat, interessiert "ihn" nicht. Die Mittelmänner (Mediator, Frequency, Provider) zählen hier ausdrücklich nicht als Objekte im oben genannten Sinne. Sie sind einfach notwendig, um die Objekte zu verbinden und dadurch Funktionalität zu gewährleisten. Man referenziert sie auch nicht, sondern sie sind einfach da.

Objekte kommunizieren vorsichtig bzw. passiv!

Das heißt, Objekte können zwar sagen, was sie wollen. Ihrem Wunsch muss aber nicht nachgegangen werden. Dadurch kann man auch mal temporär einen Kommunikationskanal unterbrechen, wenn man z.B. logische Fehler im Programm aufspüren will. Im besten Fall funktioniert dann eine Funktion nicht mehr, löst aber keine Exception aus. (Zwei Wassermoleküle kann man auch trennen, ohne dass die Welt untergeht. Bei der Software sollte es IMHO auch so sein.)

Man kann agil und flexibel seine Software entwickeln!

Schon lange vorbei sind die Zeiten, wo man vorher erstmal großartig seine Software plant. (Und das möglichst noch mit UML.) Man entwirft höchstens im Kopf mal ein grobes Konzept, wie das Gesamtbild aussehen soll.

Software darf man IMHO nicht mit einem statischen Gebäude vergleichen. Software ändert sich ständig! Da kann ich wirklich ein Lied von singen. Besonders, wenn eine recht komplexe Änderung in recht kurzer Zeit umgesetzt sein soll. (Sehr lustig wird es, wenn dann plötzlich Probleme auftreten, mit denen man gar nicht gerechnet hat.)

Mit der MPT kann man quasi die Software so entwickeln, wie sie einem der Kunde von der Funktionalität her erklärt. Einen "Button-Klick" in der Story kann man z.B. sofort mit dem CML verknüpfen, da dieser Klick irgendwas auslösen soll. Wie es weiter geht? Das kann an dieser Stelle sogar offen bleiben. Es ist wie bei einem Puzzle, wo jenes CML Triplet einen kleinen Teil vom Ganzen ausmacht. Man platziert es erstmal irgendwo und nimmt sich das nächste Puzzle-Teil her. Dies kann z.B. ein völlig anderer Aspekt sein, der mit dem "Button-Klick" gar nix zu tun hat.

Diese Freiheit hat man nur deshalb, weil alle Triplets atomar und völlig unabhängig voneinander sind. Am Ende hat man aber ein "fertiges" Puzzle bzw. eine funktionale Software, welche das tut, was sie soll.

Durch Schnittstellen werden die Dinge miteinander verknüpft!

Das ist sogar ganz wichtig, bei diesem Konzept! Die Mittelmänner erwarten ausschließlich Schnittstellen als Konstruktor-Argument! Niemals eine konkrete Klasse! Dies wäre ein fataler Bruch bei der MPT und die Flexibilität wäre dahin.

Vielmehr sollte man den Vorteil darin sehen, dass eine Klasse beliebig viele Schnittstellen implementieren kann. (Zu diesem Thema wird es auch noch einen extra Beitrag geben, weil die Schnittstellen so wichtig sind.)

So kurze Datenwege, wie möglich!

Theoretisch dürften hier die transportierten Daten (siehe TFR und CPS) auf kürzestem Wege beim Ziel ankommen, weil das jeweilige Objekt direkt sagt, was es benötigt. (z.B. beim CPS)

Somit könnte das angeforderte "Ding" direkt übermittelt werden, ohne erst über zig Ecken wandern zu müssen. Wie gesagt, theoretisch! ;-)

So, das wären spontan die Vorteile. Das ganze hat leider auch einen offensichtlichen Nachteil:

SEHR AUFWÄNDIG!

Für jedes Triplet muss man zwei Schnittstellen anlegen und den Mittelmann vollständig implementieren.

Zudem werden da auch viele einzelne kleine Quellcodedateien anfallen.

Ja, das ödet wirklich sehr an und wäre zurecht ein Grund zu sagen: "OMG, da bleibe ich lieber bei quick & dirty!"

Da bleibt momentan nix anderes übrig, als in den sauren Apfel zu beißen oder es zu lassen.

(Ich habe da aber schon ein privates Projekt im Sinn, welches eine Art RAD-Tool werden soll, um mir diese Arbeit abzunehmen. Natürlich möchte ich dieses Tool konsequent mit der MPT ins Leben rufen. Das wäre dann auch gleich die beste Erprobung für die Praxistauglichkeit der MPT.)

Soviel dazu. Bis zum nächsten Artikel! :-)

"Client - Provider - Server" im Detail

noreply@blogger.com (Anonymous) — Sun, 18 Apr 2010 16:31:00 +0000

Im letzten Beitrag habe ich erklärt, wie das Transmitter-Frequency-Receiver Triplet (kurz TFR) funktioniert.

Nun ist das letzte Triplet der "Micro-Pattern-Trilogie" dran: das Client-Provider-Server Triplet (kurz CPS).

Wie kam ich auf das CPS Triplet? Das ergab sich aus der Tatsache, dass es neben einer passiven Datenübertragung auch eine Aktive geben muss. Einerseits würde das Konzept, ohne die Möglichkeit der Datenübertragung auf Abruf, unvollständig erscheinen. Zum Anderen ist dies sogar unabdingbar, wenn man konsequent ausschließlich mit dieser "Micro-Pattern-Trilogie" seine Software entwickelt. Was ich damit meine, wird in den zukünftigen Artikeln ersichtlicher werden. Es sei nur kurz erwähnt, dass es damit zu tun hat, wie man derartige Software zu entwickeln beginnt. (Das werde ich aber in anderen Beiträgen ausführlich erklären und würde hier zu weit führen.)

Bei der Namensfindung orientierte ich mich auch wieder am realen Beispiel:
Ich (der Client) suche etwas bei Google (der Server). Dabei wandern meine Suchanfragen und meine persönlichen Suchergebnisse von Google über den Provider.

Damit sollte die Sache eigentlich schon klar sein.
Hier nun die Präsentation:

So, nun sind alle Triplets in ihrer Funktionsweise erklärt und wir tasten uns langsam aber sicher zu den praktischen Beispielen vor.

"Transmitter - Frequency - Receiver" im Detail

noreply@blogger.com (Anonymous) — Sat, 17 Apr 2010 19:45:00 +0000

Im letzten Beitrag habe ich erklärt, wie das Caller-Mediator-Listener Triplet (kurz CML) funktioniert.

Nun möchte ich erklären, wie das Transmitter-Frequency-Receiver Triplet (kurz TFR) funktioniert.
Wie bin ich überhaupt darauf gekommen? Der Gedankengang war im Grunde recht einfach. Da das CML Triplet keine Daten übertragen darf, musste etwas her, was dies ausdrücklich spezifiziert.
Ich dachte zuerst an eine Möglichkeit, Daten passiv empfangen zu können. Als Beispiel sei hier die Statusleiste genannt, welche bei fast allen GUI-Anwendungen existiert. Diese Statusleiste fordert keine Daten an, sondern empfängt diese automatisch, wenn sich der Status geändert hat. (Meist ist dies ja ein einfacher String.)

Oder ein anderes Beispiel:
Der Benutzer gibt z.B. in einer TextBox beliebigen Text ein, welcher gleichzeitig in mehreren Ansichten aktualisiert werden soll.

Mit diesem Beispiel kam mir letztlich die Idee:
Es gibt einen Sender, welcher Daten aussendet. Gleichzeitig kann es mehrere Empfänger geben, welche diese Daten empfangen.
So etwas kennt jeder aus dem realen Leben: Fernsehsatelliten senden ein Fernsehsignal in Richtung Erde und diverse Sat-Empfänger können dieses Signal empfangen.
Es war sofort klar, dass die Schnittstelle für den Empfang schlicht Receiver heißen musste.
Die Schnittstelle für den Sender wollte ich auch erst "Sender" nennen, jedoch gab es diese Bezeichnung schon im .NET Framework. Außerdem klang es nicht so "cool".
Einmal kurz gegoogelt und ich fand den Begriff Transmitter. Dieser passt auch besser zum Rundfunk-Beispiel.
Nun brauchte ich noch einen geeigneten Name für den Mittelmann.
Was verbindet beide Dinge miteinander? Wirklich spontan fiel mir sofort der Äther ein. Ich gebrauchte natürlich den englischen Begriff Aether. Tatsächlich blieb ich für einige kurze Experimente bei diesem Begriff, aber mich störte er immer mehr, weil man ihn heute im Grunde nur noch in der Esoterik antrifft.
Ich überlegte und überlegte, aber mir wollte keine Alternative einfallen. Dann nahm ich mir in Gedanken nochmal den Vergleich mit dem Rundfunk her. Was geschieht also, wenn man z.B. beim Sat-Receiver oder beim Radio den Sender wechselt? Klar, man ändert die Frequenz. Bingo! Das war der gesuchte Begriff! Und er passte auch genau zu dem Presenter-First Konzept. Auch hier entschied ich mich letztlich für die englische Bezeichnung: Frequency.

Nach der langen Einleitung kommt nun die versprochene Präsentation:

So, dieses war der zweite Streich und der Dritte folgt sogleich!

(Mal sehen, ob ich es bis morgen Abend schaffe. Dann hätten wir die graue Theorie hinter uns und es folgen dann endlich praktische Beispiele und Überlegungen für den praktischen Einsatz.)

"Caller - Mediator - Listener" im Detail

noreply@blogger.com (Anonymous) — Thu, 25 Mar 2010 20:24:00 +0000

In meinem ersten Beitrag hatte ich die Idee des "Caller - Mediator - Listener" Triplets kurz erklärt. Nun möchte ich dieses im Detail erläutern und erklären, was ich mir dabei gedacht habe.

Der Grundgedanke, den ich hatte, war letztlich gar nix weltbewegend Neues.
Ich habe einfach den Sachverhalt der Objektkommunikation aus der objektorientierten Programmierung wörtlich genommen.
Somit gibt es eben:

einen Caller, der etwas zu sagen hat
einen Mediator, der die Botschaft vom Caller empfängt und weiterleitet
einen Listener, der letztlich die Nachricht empfängt und die eigentlichen Befehle durchführt

Damit das ganze noch anschaulicher wird, habe ich eine Präsentation erstellt. Ich hoffe, es ist anschaulich genug.

(Da es sich aber hierbei um eines der einfachsten der insgesamt 3 Triplets handelt, sehe ich da keine Probleme.)

So, die nächsten beiden Triplets werden auf jeden Fall interessanter, denn da werden Daten übertragen! Da gibt es dann auch schönere Anwendungsbeispiele.
Als Vorlage werde ich gleich wieder diese Präsentation verwenden, dann bereitet es nicht ganz so viel Arbeit.

PS.:
Alle Dateien, die hinsichtlich dieses Blogs anfallen, findet man auch in einem öffentlichen Ordner: KLICK

Es dauert noch etwas ...

noreply@blogger.com (Anonymous) — Mon, 22 Mar 2010 21:57:00 +0000

Eigentlich wollte ich die 3 Triplets heute in einem Beitrag in Textform erklären.
Mir kam aber eine bessere Idee in den Sinn!
Da Bilder bekanntlich mehr sagen, als 1000 Worte, beschloss ich diese Triplets mithilfe einer Präsentation zu beschreiben.
Dazu verwende ich Google Text & Tabellen.
Es funktioniert bis jetzt alles wunderbar und auch die grafischen Funktionen machen keine Probleme.

Man darf sich also auf 3 anschauliche Präsentationen freuen. (Zumindest hoffe ich, dass sie anschaulich genug sein werden. *g*)

Das ganze ist jedoch etwas aufwändig. Aber sobald die erste Präsentation fertig ist, werde ich sie hier im Blog veröffentlichen. Bis dahin bitte ich um etwas Geduld! :-)

Presenter First - Geniale Idee!

noreply@blogger.com (Anonymous) — Sun, 21 Mar 2010 21:13:00 +0000

Meinen ersten Beitrag beginne ich sogleich mit einem Konzept, welches sich "Presenter First" nennt. Ich möchte hier nicht die Grundlagen dessen ausschweifend erklären.
Hierzu verweise ich lieber auf zwei Dokumente von den eigentlichen "Erfindern".

Da wäre zunächst das eigentliche Paper, welches die Sache konzeptionell erklärt:
Presenter First: Organizing Complex GUI Applications for Test-Driven Development [pdf] [doc01]

Und dann noch ein eher praktisches Beispiel, welches in dem Magazin "Better Software" erschien:
Big, Complex, and Tested? Just Say ‘When’ [pdf] [doc02]

Nun, als ich das erste mal von diesem Konzept hörte, war ich von dieser Idee total angetan.[1]
Man stellt sich dann aber dennoch die Frage: "Wo fange ich da nun am besten an, meine Software zu entwerfen?"
Klar, bei dem gewünschten Feature. Das ist ja der Sinn von dem Konzept.
Das mag auch noch einfach sein, wenn das Feature in etwa so aussieht: "Wenn ich auf den Button [Beenden] klicke, soll die Anwendung beendet werden."
Das ist auch soweit einfach, wenn hierbei wirklich nur die Anwendung beendet werden soll und sonst nix weiter.
Was aber, wenn mit diesem einfachen Feature komplexe Aufräumarbeiten verbunden sind? Vielleicht soll der Benutzer noch gefragt werden, ob sein geändertes Dokument vorher gespeichert werden soll? Etc.
Da ist das zuerst genannte Feature die höchste Abstraktionsebene.
Aus der "Presenter First"-Sicht ist das im Grunde auch so richtig. Was mit dem Beenden-Vorgang sonst noch zusammen hängt, interessiert in dieser Abstraktionsebene überhaupt nicht. Das ist ja auch Sinn und Zweck dieser strikten Entkopplung.
Es stellt sich daher die Frage: "Wie tief und fein sollte die Abstraktion sein? Das heißt, erstelle ich sehr viele kleine Sub-Presenter, oder sollte das an der Stelle doch etwas grober ausfallen?"

Desweiteren stand ich schon vor folgendem Problem:
Sollte zu jedem Presenter auch nur ein Fenster/Dialog gehören? Oder sollte jeder Button/jede Komponente einen eigenen Presenter bekommen?
Ersteres macht die ganze Sache sehr einfach und übersichtlich, ist aber sehr unflexibel und problematisch, wenn man z.B. noch einen Adapter oder generell noch weitere Abstraktionsebenen zwischen eine einzelne Komponente des User Interfaces schalten will.
Bei der anderen Variante gäbe es nicht dieses Problem. Aber hier hat man am Ende Unmengen einzelner Schnittstellen-, Presenter-, Model- und View-Klassen.

Nun, die Erfinder meinen hier, man solle logisch zusammengehörige Komponenten gemeinsam mit einem Presenter verbinden.
Klar, das ist erstmal ein guter Kompromiss. Da könnte man die Komponente, welche noch weitere Adapter braucht, entsprechend separieren und die anderen Komponenten zusammen halten.
Allerdings ist mir das zu willkürlich.

Und das ist gleich das Nächste. Die Willkürlichkeit, wie die Model-View-Presenter-Einheiten zusammengesetzt sind. Das heißt, bei dem originalen Konzept sieht man nicht direkt von Außen, wie der Daten- und Nachrichtenfluss verläuft. Das heißt, jemand, der den Quellcode zum ersten Mal sieht, wird nicht auf Anhieb wissen, was dieses Model oder jene View macht oder welche Rolle der Presenter dabei spielt.
Dazu müsste man sich nämlich erst tiefer in den Quellcode einlesen.

Ich grübelte noch einige Zeit über die oben genannten Probleme. Immer wieder las ich mir die Dokumente durch.
Irgendwann ließ ich mir folgenden Text [doc02; letzte Seite unten] so richtig auf der Zunge zergehen:

The “micro-architecture” of Presenter First is like a carbohydrate chain in organic chemistry — interesting functionality arises from applying the same basic pattern of object composition. The mechanisms and domain may vary, but the core principles do not: When the customer says “when,” write it into a presenter.

Dann war es mir klar. Was dieses an sich tolle Konzept brauchte, war eine gewisse Ordnung in dem willkürlichen Chaos. So, wie auch die Moleküle oder die Zellen des Menschen nach einer gewissen Ordnung funktionieren.
Ich übertrug den Ordnungsbegriff auf die Softwareentwicklung und kam dann zu folgender Lösung:

Jedes Objekt übernimmt einen sehr kleinen Aufgabenbereich in dem Gesamtsystem. Ein Button im UI wird höchstens nur als Auslöser für eine komplexe Aufgabe dienen. Vielleicht empfängt er auch mal Daten in Form einer neuen Beschriftung oder anderer Eigenschaftswerte. Aber in erster Linie wird er nur zum Triggern da sein.

Somit übernimmt der Button eine entscheidende Aufgabe: Er ist ein Caller!
Aber ein Caller alleine bringt leider nicht viel. Es muss auch jemand auf das bestimmte Signal hören, was der Caller ausgesandt hat. Also muss es noch einen Listener geben.
Aber da fehlt noch einer! Caller und Listener sollen ja nix voneinander wissen. Ein Presenter muss immer existieren, der beide miteinander verbindet. Aber die Bezeichnung "Presenter" passt hier nicht gut. Zwischen einem "Rufer" und einem "Zuhörer" muss noch jemand vermitteln. Dies wäre im klassischen Sinne die "Luft". "Air" klingt aber komisch, weshalb ich mich hier für Mediator entschieden habe.

Das ist nun also die erste Triplet-Gruppe von insgesamt 3 Gruppen, die ich mir ausgedacht habe, um ein bisschen Ordnung und Struktur in die Sache zu bekommen.

Caller - Mediator - Listener

Die anderen Beiden nenne ich jetzt erstmal so, ohne Erläuterung.

Transmitter - Frequency - Receiver
und
Client - Provider - Server

In den nächsten Beiträgen werde ich diese 3 Triplets genauer beleuchten.
(Theoretisch sollte sich schon die Funktion der letzten 2 Triplets anhand der Bezeichnungen erahnen lassen. *g*)

Das soll es aber erstmal für heute gewesen sein.

Und ich bin noch immer davon begeistert. Doch ich habe noch so ein paar Schwierigkeiten damit, weshalb ich dieses Konzept noch nicht auf Arbeit verwende. Das werde ich aber in diesem und weiteren Blogbeiträgen nach und nach erläutern.