OOP und Flow Design sind wie Yin und Yang

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

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