Feingranular – Methoden als Event-Based Components

Mit Event-Based Components können Sie sehr schön top-down, bottom-up oder nach dem Jo-Jo-Prinzip entwerfen. Es ist egal.

Holarchische Modellierung

Fangen Sie einfach an. Malen Sie einfach Systeme von Funktionseinheiten, die Ihr Problem durch den Austausch von Nachrichten lösen.

Diese Funktionseinheiten sind einfach Verantwortlichkeiten. Wie sie später mal implementiert werden…? Keine Ahnung. Während der Entwurfszeit, mache ich mir da nicht viele Gedanken. Ich male einfach hin, was mir auf dem aktuellen Abstraktionsniveau in den Sinn kommt, das hilfreich sein könnte. Für eine kleine Funktionsplotteranwendung sind das halt zunächst diese beiden Funktionseinheiten.

Wenn ich dann aber weiter überlege, dann fallen mir natürlich Subfunktionalitäten ein, z.B.

Was werden denn die eingeschachtelten EBCs in der späteren Implementierung? Immer noch keine Ahnung. Muss auch nicht sein. Es sind halt Funktionseinheiten, die mir sinnvoll erscheinen. Sie zerlegen die große ganze Funktionalität in besser handhabbare Teilfunktionalitäten. Je weiter mein Verständnis der Problemdomäne voran schreitet, desto mehr solcher Teilfunktionalitäten erkenne ich. Wenn ich z.B. darüber nachdenke, wie so ein Compiler aussieht, dann komme ich auf folgende Verfeinerung:

Was sind Scanner und Parser nun am Ende in der Implementation? Keine Ahnung. Damit muss ich mich während des Entwurfs nicht beschäftigen. Das ist das schöne an einer “holarchischen Modellierung” :-)

Holarchisch ist dieser Entwurf, weil das System der Funtionseinheiten hierarchisch ist und auf jeder Ebene wieder aus “Teil-Ganzen” (Holon)  besteht. Jedes Blatt einer Ebene (im letzten Bild z.B. Parser) kann jederzeit weiter zerlegt werden. So ein EBC-Softwaresystem ist eine selbstähnliche Struktur, quasi fraktal :-)

Ein Modell ist dieser Entwurf, weil die Elemente eben keine Codeartefakte sind. Ich denke beim EBC-Entwurf nicht in Assemblies oder Klassen oder Methoden. Ob eine Funktionseinheit wie Plotter oder Scanner am Ende als dieses oder jenes Artefakt implementiert wird, das ist während des Entwurfs unwichtig. Der soll nur ein problemlösendes System entwickeln.

So weit, so gut.

Nach dem Entwurf kommt aber natürlich irgendwann doch die Implementation. Dann müssen Sie sich Gedanken machen, wie Sie die geplanten Funktionseinheiten übersetzen.

Funktionseinheiten in Klassen übersetzen

In den bisherigen Blogartikeln habe ich EBCs immer in Klassen übersetzt. Aus einem Blatt ist dort eine EBC-Bauteil-Klasse  geworden, deren Input-Pins Methoden und deren Output-Pins Events waren. (Statt Events werde ich in Zukunft jedoch normale Delegaten benutzen. Events haben einen Sonderstatus als Delegaten, der den Umgang mit Ihnen in generischer Weise manchmal erschwert.)

Das ist eine sinnige Übersetzung für die allermeisten Fälle, denke ich, die auch für Nicht-Blätter ausreicht. EBC-Platinen, d.h. Funktionseinheiten, die andere aggregieren, enthalten allerdings keine eigene Domänenfunktionalität, sondern nur Code, um ihre Konstituenten zu verdrahten. Das passiert im folgenden Beispiel im Konstruktor.

Diese Übersetzungen für Bauteile und Platinen reichen eigentlich völlig aus, um beliebig tief geschachtelte Systementwürfe in Code zu manifestieren. Es gibt keinen Impedance Mismatch zwischen Modell und Implementierung.

Funktionseinheiten in Methoden übersetzen

Eigentlich könnte ich zufrieden sein mit der Übersetzung von EBCs in Klassen. Aber irgendwie wurmt es mich, dass ich mit einerseits bei der Modellierung keine Gedanken machen soll darüber, wie die Implementierung einer Funktionseinheit aussieht. Andererseits jedoch werde ich quasi gezwungen, darüber nachzudenken, ob denn eine Funktionseinheit auch nicht kleiner als eine Klasse sei. Zwar sollte ein Architekturentwurf mit EBCs nicht zu detailliert ausfallen; immerhin soll sich ein Architekt nicht um Klassen, sondern um Komponenten kümmern. Doch irgendwie kann ich der Zerlegung nicht freien Lauf lassen, wenn Blätter zwangsweise in Klassen übersetzt werden müssen.

Beim Funktionsplotter macht mir das noch keine Probleme. Scanner, Parser, Codegenerator sind umfangreich genug, um eine Übersetzung in Klassen zu rechtfertigen. Doch wie steht es mit einer Übersetzung einer Zeichenkette in ein Dictionary? Aus “a=1;b=2;…” soll ein Dictionary<string, string> werden.

Ein Softwaresystem könnte ich mir dafür so vorstellen:

Wenn ich´s jedoch genauer bedanke, dann lohnen eigene Klassen für die Blätter in dieser Holarchie nicht. SplitInfoPairs usw. sind so einfach, dass diese Funktionseinheiten als Methoden implementiert werden können. Das erkenne ich jedoch erst am Ende; während des Entwurfs habe ich mir darüber keine Gedanken gemacht, sondern das Gesamtproblem soweit in EBCs zerlegt, wie ich Ideen für die Verarbeitungsschritte hatte.

Wenn ein Problem vor Ihnen liegt, wissen Sie einfach nicht, wie tief Sie ein Lösungssystem schachteln können, ohne zu implementiere. Deshalb wissen Sie auch nicht, ob Sie am Ende nicht bei Funktionseinheiten ankommen, die im Grunde zu klein für eine Implementierung in eigenen Klassen sind.

Aber wie können EBC-Bauteile, also Blätter des Zerlegungsbaumes, genauso systematisch in Methoden überführt werden wie in Klassen? Bei Klassen sind die Übersetzungen von Input- und Output-Pins klar. Was entspricht denen aber bei Methoden?

Ich glaube, folgende Übersetzungen sind naheliegend:

Blätter, die in Methoden übersetzt werden sollen, haben nur 1 Input-Pin, aber beliebig viele Output-Pins. Der Input kommt als Parameter in die Methode, wie bei den Input-Pin-Methoden von Klassen-EBCs. Für den Output gibt es allerdings keine globalen Output-Pin-Delegaten; stattdessen werden die ebenfalls als Parameter hineingereicht.

Warum keine Übersetzung dieser Blatt-EBCs in Funktionen? Weil ein Rückgabewert pro Input-Nachricht nur einmal geliefert werden kann. Wenn ein Input jedoch n>1 oder n=0 Output-Werte erzeugen kann, dann ist deren Lieferung über einen Rückgabewert nur umständlich möglich.

Im Sinne einer systematischen Übersetzung bin ich deshalb dafür, kleine Blatt-EBCs immer in Methoden nach dem obigen Schema zu übersetzen. Das mag zunächst eine wenig umständlich erscheinen, doch ich denke, die Regelmäßigkeit und damit leichtere Verständlichkeit ist dafür eine Entschädigung. Denken Sie also nicht über die “beste” Übersetzung nach, sondern konzentrieren Sie sich auf die Ausfleischung der systematisch erzeugten Form.

Eine Ausnahme finde ich allerdings doch akzeptabel: Wenn eine Blatt-Funktionseinheit nur einen Output-Pin hat, kann sie als Funktion mit Rückgabewert IEnumerable<T> definiert werden. So sind auch n=0 und n>1 Rückgabewerte möglich.

Das eröffnet auch Möglichkeiten der Verkettung von EBC-Methoden mittels Linq.

Für Platinen bedeuten Methoden als EBCs natürlich eine Veränderung der Verdrahtung:

Die Verdrahtung bleibt beschränkt auf den Konstruktor. Deshalb leitet der Input-Pin der Platine die Nachricht weiter an einen Delegaten, der die eigentliche Methode “umwickelt”. Der Input-Pin weiß dadurch nichts von einem evtl. Output des Pins, an den er weiterleitet.

Dasselbe gilt für die Output-Pins, die an die Methoden übergeben werden. Auch das sind Delegaten, um dem Methoden-EBC Details über die Weiterverarbeitung seines Output zu verbergen.

Ob die Platine wie hier die Methoden-EBCs selbst implementiert und somit nicht mehr sauber nur verdrahtet, sondern auch Domänenfunktionalität implementiert, ist nicht so wichtig. Ich finde das erstmal ok. Aber Sie können natürlich auch die Methoden als Delegaten via ctor-Parameter injizieren. Oder Sie könnten eine Basisklasse definieren, die nur die Methoden-EBCs implementiert und die Platine davon ableiten.

Funktionseinheiten im Flow

Methoden-EBCs wie eben gezeigt zu verdrahten, ist simpel, aber etwas nervig. Die temporären Variablen für die Lambda Funktionen machen den Code unübersichtlich. Deshalb komme ich hier auf ein Thema zurück, dass ich schon früher hier im Blog am Wickel hatte: Flows.

Wenn Methoden-EBCs so regelmäßig gebaut sind, dann ist dafür auch etwas Toolunterstützung möglich. Hier meine Idee davon, wie ein Flow-API für EBCs die Verdrahtung von Methoden-EBCs erleichtern könnte. Statt die Methoden mit Hilfsvariablen und auch noch in umgekehrter Reihenfolge zusammenzustecken

public B2()
{
  Action<W> input_z = m => Z(m, this.Output);
  Action<V> input_y = m => Y(m, input_z);
  this.input_x = m => X(m, input_y);
}

könnten Sie sie in besser lesbarer Form verdrahten:

public B2()
{
    this.input_x = Flow
                     .StartWith<string, StringBuilder>(X)
                     .Then<int>(Y)
                     .Then<bool>(Z)
                     .Finally(b => this.Output(b));
}

Hier ist vor allem die Reihenfolge erhalten, so wie die Nachrichten durch die EBCs fließen, von X nach Y nach Z.

Die Implementation des APIs dafür sieht so aus:

public static class Flow

{

    public static Flow<TInput, TOutput> StartWith<TInput, TOutput>(Action<TInput, Action<TOutput>> stage)

    {

        return new Flow<TInput, TOutput>(GenerateInputPinFactory<TInput, TOutput>(stage));

    }

 

 

    internal static Func<Action<TOutput>, Action<TInput>> GenerateInputPinFactory<TInput, TOutput>(Action<TInput, Action<TOutput>> stage)

    {

        return outputPin => message => stage(message, outputPin);

    }

}

 

 

public class Flow<TInput, TOutput>

{

    private readonly Stack<Delegate> inputPinFactories;

 

 

    internal Flow(Delegate inputPinFactoryForStage)

    {

        this.inputPinFactories = new Stack<Delegate>();

        this.inputPinFactories.Push(inputPinFactoryForStage);

    }

 

    internal Flow(Stack<Delegate> inputPinFactories,

                  Delegate inputPinFactoryForStage)

    {

        this.inputPinFactories = inputPinFactories;

        this.inputPinFactories.Push(inputPinFactoryForStage);

    }

 

 

    public Flow<TInput, TNextOutput> Then<TNextOutput>(Action<TOutput, Action<TNextOutput>> stage)

    {

        return new Flow<TInput, TNextOutput>(this.inputPinFactories,

                                            Flow.GenerateInputPinFactory(stage));

    }

 

 

    public Action<TInput> Finally(Action<TOutput> stage)

    {

        Delegate inputPin = stage;

        while(this.inputPinFactories.Count() > 0)

        {

            Delegate inputPinFactory = this.inputPinFactories.Pop();

            inputPin = (Delegate)inputPinFactory.DynamicInvoke(inputPin);

        }

        return (Action<TInput>)inputPin;

    }

}

Mit jedem Do<>() wird eine Factory-Methode auf einen Stack gelegt. Diese Methoden erzeugen später die Input-Pin-Delegaten für die Methoden. Die wiederum werden an die nächste Factory-Methode übergeben. Das geschieht in der handgeschriebenen Version mittels der temporären Delegaten wie input_z.

Fazit

Ich denke, es spricht für EBCs, dass das Konzept sich auch auf Methoden ausdehnen lässt. Bei der Planung müssen Sie sich nicht beschränken. Wenn Sie fertig sind mit dem Architekturentwurf auf beliebig vielen Abstraktionsebenen des Lösungssystems, dann schauen Sie einfach, wie Sie die Blätter des Funktionseinheitenbaums implementieren. Für viele werden sich Klassen anbieten. Für manche aber sicherlich Methoden. Für Platinen-Klassen, Bauteil-Klassen und auch Bauteil-Methoden haben Sie nun Implementierungsregeln.

Ich finde das sehr beruhigend. Denn so kann ich mich einerseits auf den Entwurf konzentrieren; dabei muss ich nicht immer im Hinterkopf schon die Frage der Implementierung wälzen. Und andererseits kann ich mich bei der Implementierung auf die Domänenlogik konzentrieren, d.h. das Ausfleischen der Funktionseinheiten; ich muss mir den Kopf nicht über ihre Form zerbrechen.

Systematik und Regelmäßigkeit helfen, den Blick auf dem Wesentlichen zu halten. Mein Gefühl ist, davon brauchen wir mehr.