{"id":191,"date":"2015-03-21T15:39:39","date_gmt":"2015-03-21T13:39:39","guid":{"rendered":"http:\/\/invidit.de\/blog\/?p=191"},"modified":"2015-07-04T14:37:55","modified_gmt":"2015-07-04T12:37:55","slug":"wenn-daten-fliessen","status":"publish","type":"post","link":"https:\/\/invidit.de\/blog\/wenn-daten-fliessen\/","title":{"rendered":"Wenn Daten flie\u00dfen"},"content":{"rendered":"

Hallo Spa\u00df-Coder.<\/p>\n

Wer kennt noch das EVA-Prinzip? Eingabe-Verarbeitung-Ausgabe. Das war eines der ersten Themen im Informatikunterricht. Demnach also kein neuen Prinzip, was deshalb aber nicht weniger interessant ist. Insbesondere, wenn ich an das Single Resposibility Principle (SRP) denke, l\u00e4sst sich dies gut vereinbaren.<\/p>\n

Dazu hat sich insbesondere in der .Net Welt das Flow-Pattern etabliert, welches Events als Kommunikationsmedium zwischen gekapselten Funktionseinheiten (Klassen) nutzt. Hierzu findet ihr auch einige Artikel in der dotnetpro von Ralf Westphal und Stefan Lieser.<\/p>\n

Flow-Pattern<\/h2>\n

Bei der Idee hinter diesem Pattern geht es genau darum: dass Daten flie\u00dfen. Jede Klasse hat dabei nur genau eine Verantwortlichkeit – bei diesem Pattern geht es kaum noch anders. Die Grundstruktur dazu sieht wie folgt aus:<\/p>\n

    public class ExtractCharacter\r\n    {\r\n        public void Process()\r\n        {\r\n\r\n        }\r\n\r\n        public event Action<string> Progress;\r\n    }<\/pre>\n
Der Klassenname „ExtractCharacter<\/em>“ ist bereits so gew\u00e4hlt, dass die Verantwortlichkeit der Klasse klar ist. Eine Kombination aus Substantiv und Verb schafft hierbei oft Klarheit. Es gibt nur eine einzige Methode mit dem Namen „Process<\/em>„, welche alle zur Verarbeitung erforderlichen Parameter erh\u00e4lt, jedoch keinen Wert zur\u00fcckgibt. Stattdessen wird f\u00fcr die R\u00fcckgabe des Ergebnisses ein Event mit dem Namen „Progress<\/em>“ verwendet, da hier im Beispiel typisiert ist und einen „string<\/em>“ zur\u00fcckgibt. Die Action stellt hier einen Delegaten dar – einen Funktionszeiger. D.h. hier kann eine Funktion, die einen Parameter vom Typ „string<\/em>“ erh\u00e4lt, „verbunden“ werden.<\/p>\n
Weitere \u00f6ffentliche Methoden gibt es bei Anwendung des Flow-Patterns nicht, womit es bereits schwieriger wird, der Klasse verschiedene Verantwortlichkeiten zu \u00fcbertragen.<\/p>\n
Die Idee f\u00fcr das Beispiel ist, dass ein bestimmtes Zeichen aus einem angegebenen Text extrahiert wird (mag wenig sinvoll erscheinen, ist aber als Beispiel sch\u00f6n einfach ;-)).\u00a0 Meine Erwartungen dr\u00fccke ich als Unit Test aus.<\/p>\n
        [TestMethod]\r\n        public void ExtractsCorretCharacters()\r\n        {\r\n            string actual = string.Empty;\r\n            ExtractCharacter sut = new ExtractCharacter();\r\n\r\n            sut.Progress += result => actual = result;\r\n            sut.Process('e', \"Dies ist der gesamte Text.\");\r\n            actual.Should().Be(\"eeeee\");\r\n        }<\/pre>\n
Das zu testende Objekt (subject unter test – „sut“) der Klasse „ExtractCharacter“ wird erstellt. Dann wird das R\u00fcckgabe-Event „Progress“ aboniert und per Lambda-Ausdruck wird das Ergebnis „result“ der lokalen Variable „actual“ zugewiesen, um sp\u00e4ter das Ergebnis vergleichen zu k\u00f6nnen. Dann wird die Verarbeitung angesto\u00dfen per „sut.Process(‚e‘, „Dies ist der gesamte Text.“)“ und die Behauptung aufgestelllt, dass das Ergebnis = „eeeee“ ist.<\/p>\n
Dieser Test l\u00e4sst sich nat\u00fcrlich im derzeitigen Zustand der Klasse „ExtractCharacter“ nicht kompilieren, daher erg\u00e4nze ich die entsprechende Methodensignatur.<\/p>\n
    public class ExtractCharacter\r\n    {\r\n        public void Process(char characterToExtract, string textToExtractFrom)\r\n        {            \r\n        }\r\n\r\n        public event Action<string> Progress;\r\n    }<\/pre>\n
Damit l\u00e4sst sich der Test zumindest kompilieren. Wie erwartet schl\u00e4gt der Test fehl und l\u00e4uft auf rot. Warum? Unsere Klasse macht ja gerade noch recht wenig. Das wollen wir \u00e4ndern und ich erg\u00e4nze diese Implementierung:<\/p>\n
    public class ExtractCharacter\r\n    {\r\n        public void Process(char characterToExtract, string textToExtractFrom)\r\n        {\r\n            StringBuilder resultBuilder = new StringBuilder();\r\n            IEnumerable<char> stringQuery = from c in textToExtractFrom \r\n                         where c == characterToExtract select c;\r\n\r\n            stringQuery.ToList<char>().ForEach(c => resultBuilder.Append(c));\r\n            this.Progress(resultBuilder.ToString());\r\n        }\r\n\r\n        public event Action<string> Progress;\r\n    }<\/pre>\n
Da alle gefundenen Zeichen wieder als String zusammengesetz werden sollen, definiere ich einen „StringBuilder“, da dieser deutlich schneller ist, als die Operation „string += string“. Die direkte Stringverkn\u00fcpfung erzeugt bei jedem Aufruf ein neues Objekt der Klasse String<\/em> f\u00fcr das Ergebnis und braucht damit mehr Speicher als auch Zeit.<\/p>\n
Per LINQ werden jetzt alle Zeichen extrahiert, die im gesetzten Text mit dem gesuchten Zeichen \u00fcbereinstimmen und davon eine Liste erstellt („stringQuery<\/em>„). In Zeile 7 wird per Lambda-Ausdruck jedes Zeichen der Ergebnisliste aus dem verhierigen Schritt an den StringBuilder angehangen. F\u00fcr die Ergebnissr\u00fcckgabe wird abschlie\u00dfend das \u00f6ffentliche Event „Progress<\/em>“ ausgel\u00f6st und dabei die Verkn\u00fcpfung aller gefundenen Zeichen als „string<\/em>“ mitgegeben.<\/p>\n
Eine erneute Ausf\u00fchrung des Test signalisiert: alles gr\u00fcn und damit ist meine formulierte Erwartung erf\u00fcllt.<\/p>\n
Implementieren wir eine weitere Klasse nach dem Flow-Pattern, welche die Anzahl Zeichen in einem Text z\u00e4hlt und die Anzahl als Ergebnis zur\u00fcck gibt. Mein Anforderung definiere ich wie folgt:<\/p>\n
        [TestMethod]\r\n        public void CorrectCharacterCount()\r\n        {\r\n            int characterCount = 0;\r\n            CountCharacters sut = new CountCharacters();\r\n            sut.Progress += result => characterCount = result;\r\n            sut.Process(\"eeeee\");\r\n\r\n            characterCount.Should().Be(5);\r\n        }<\/pre>\n
Wie oben erstelle ich die neue Klasse CountCharacters, aboniere das Ergebnis, f\u00fchre die Funktion aus und behaupte, das Ergebnis ist 5 (diesmal nicht 42). Meine schnellste Implementierung, bis der Test gr\u00fcn wird, sieht so aus:<\/p>\n
    public class CountCharacters\r\n    {        \r\n        public void Process(string textToCountCharactersIn)\r\n        {\r\n            this.Progress(textToCountCharactersIn.Count<char>());\r\n        }\r\n\r\n        public event Action<int> Progress;\r\n    }<\/pre>\n
Jetzt haben wir zwei sehr kleine Klassen erstellt, die jeweils genau ein Verantwortlichkeit haben. Was machen wir jetzt damit? Hier kommt jetzt die Modularit\u00e4t des Flow-Pattern zur Geltung. Wir k\u00f6nnen unsere kleinen Komponenten miteinander verkn\u00fcpfen, sofern wir dabei auf die ein- und ausgehenden Parameter achten. Zur Demonstration erstelle ich einen Intrationstest (klassen\u00fcbergreifend).<\/p>\n
        [TestMethod]\r\n        public void ExtractAndCountCharacterInText()\r\n        {\r\n            int actual = 0;\r\n            ExtractCharacter extractCharacter = new ExtractCharacter();\r\n            CountCharacters countCharacters = new CountCharacters();\r\n\r\n            extractCharacter.Progress += countCharacters.Process;\r\n            countCharacters.Progress += result => actual = result;\r\n\r\n            extractCharacter.Process('e', \"Dies ist der gesamte Text.\");\r\n            actual.Should().Be(5);\r\n        }<\/pre>\n
Zun\u00e4chst werden alle erforderlichen Objekte erstellt. Jetzt kommt die Verkn\u00fcpfung unserer kleinen Bausteine: die Methode „Process<\/em>“ des Objekts „countCharacters<\/em>“ mit dem Eingangsparameter wird gebunden an das Event „Progress<\/em>“ des Objekts „ExtractCharacter<\/em>„. Das funktioniert deshalb, weil „ExtractCharacter“ einen Wert vom Typ „string<\/em>“ zur\u00fcckgibt.\u00a0 In Zeile 9 wird wieder das Ergebnis der lokalen Variable „actual“ zugewiesen, damit dieses sp\u00e4ter verglichen werden kann.<\/p>\n
Wenn wir nun in Zeile 11 die Methode „Process<\/em>“ des Objekts „extractCharacter<\/em>“ aufrufen, wird dort das Ergebnis (die extrahierten ‚e’s) direkt an „Process<\/em>“ von „countCharacters<\/em>“ \u00fcbergeben.<\/strong><\/p>\n
Wenn ich nun per Flow-Pattern einen ganzen Baukasten von kleinen Funktionseinheiten mit definierten Ein- und Ausgangsparameter erstelle, kann ich diese – je nach Anforderung – flexibel miteinander verbinden. Das ist angewandtes Single Responsibilit\u00e4t Principle und damit echte Wiederverwendbarkeit.<\/p>\n
Eine konfigurative Unterst\u00fctzung beim Verketten von Einheiten bietet eine Flow-Engine wie z.B. von Ralf Westphal. Weitere Informationen und die Engine findet ihr unter http:\/\/blog.ralfw.de\/2013\/01\/beispielhafte-nichtbeachtung.html<\/a>.<\/p>\n
 <\/p>\n
Zusammenfassung<\/h2>\n
In diesem Artikel haben wir uns angeschaut, das das Flow-Pattern ist und wie es dabei unters\u00fctzten kann, Software modular zu gestalten und das SRP ganz leicht anzuwenden. Wie das zum Thema „Objektorientierung wie sie gemeint war“ passt, k\u00f6nnt ihr unter http:\/\/geekswithblogs.net\/theArchitectsNapkin\/archive\/2013\/09\/08\/oop-as-if-you-meant-it.aspx<\/a> nachlesen.<\/p>\n
 <\/p>\n
Viel Spa\u00df beim Ausprobieren und Happy Coding w\u00fcnschen<\/p>\n
eure Spa\u00df-Coder<\/p>\n
 <\/p>\n
Verwendete Werkzeuge:<\/em><\/p>\n