Dieses Blog durchsuchen

Montag, 10. September 2012

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