Think First Development

Dieses mal ein etwas ausführlicher Blog zum Thema meines Vortrages bei bonn-to-code. Meine viel zu kurzen 20 Minuten hatten eine volle Agenda mit verschiedenen Varianten des Observer Pattern bis hin zu einem Message Dispatcher . Log geht’s!

Events statt Attach/Detach

Das Observer Pattern nach GOF war den meisten (oder allen) Zuhörern bereits bekannt, also konnte direkt mit der ersten .NET Modifikation begonnen werden. Die Logik des Attach und Detach von Beobachtern lässt sich wunderbar durch Events und EventHandler ersetzen. Events implementieren genau diese Funktionalität: Eine Liste von Funktionen zu verwalten und letztlich diese aufzurufen. Durch diesen Umbau ist der Code deutlich schlanker geworden und der Verwaltungscode wurde aus dem Subjekt entfernt.

Statusänderungen im größeren Kontext

Das Observer Pattern bietet eine sehr gute Möglichkeit, Statusänderungen an betroffene Ansichten durchzureichen. Dabei wird das Hollywood Prinzip (“Don’t call us, we call you”) beachtet, nachdem das Subjekt die Beobachter informiert und nicht die Beobachter regenmäßig das Subjekt überprüfen. Ein Problem entsteht, wenn mehrere Subjekte zu unterschiedlichen Zeitpunkten angezeigt werden sollen. Ein gutes Beispiel ist eine Liste aus Subjekten mit verschiedenen Vorschau-Ansichten. Nun wird es schwierig, das neue Subjekt an die unbekannte Anzahl an Ansichten zu senden.

Die Lösung hierfür ist ein SubjectNotifier mit statischen Events zum Verteilen von Nachrichten an alle Beobachter. Jeder Beobachter kann mittels SubjectStateChanged eine auf Statusänderung und mittels SubjectSelected auf eine Subjektänderung reagieren. Über die Raise* Methoden können beliebige Ansichten die entsprechenden Event auslösen, falls sich der Status oder das Subjekt geändert hat.

Fazit

Diese Variante, Statusänderungen eines Subjekts über einen SubjectNotifier zu publizieren, hat mehrere Vorteile. Alle Subjekte (auch neue Instanzen) können über einen zentralen Dispatcher publiziert werden. Es erweitert das Hollywood Prinzip aus dem klassischen Observer Pattern insoweit, dass nicht nur der Beobachter mit DEM Subjekt verbunden ist, sondern das der Beobachter noch nicht einmal das Subjekt kennt sondern von irgendwelchen Subjekten benachrichtigt wird. Ein weiterer Vorteil ist, dass das Subjekt absolut keine Logik zum Verteilen und Verwalten von Statusänderungen enthält. Das Subjekt ist unabhängig von interner Verwaltungslogik die nur einzelne Applikationen betrifft und z.B. in Konsolenanwendung nicht benötigt wird.

… dieses war der erste Streich, doch der zweite folgt sogleich!

Nachdem ich mich die letzte Woche mit PostSharp beschäftigt habe schreibe ich hier nun mein Ergebnis: AOP mit PostSharp ist einfach genial. So einfach möchte ich es auch nicht machen, also etwas mehr Informationen.

PostSharp ist ein Framework zum Implementieren von Aspekt Orientierter Programmierung (AOP). Das Ziel ist eine nachträgliche und separate Implementierung von Aspekten in eine Applikation. Klassische Beispiele hierfür sind Logging und Security. PostSharp ist so implementiert, dass die Aspekte mittels Attribut an Methoden, Eigenschaften usw. gehangen werden. Der Post-Compiler von PostSharp ändert nach dem Kompilieren durch Visual Studio die Assembly. PostSharp kann hier heruntergeladen werden. Zum Abschluss noch ein interessanter Hinweis. PostSharp kopiert die Assemblies in das Ausgabeverzeichnis die auf dem Client benötigt werden. PostSharp muss auf den Client nicht installiert werden.

Funktionsweise von PostSharp (Bild: PostSharp)

Das folgende Beispiel zeigt eine DoSomething Methode, welche über einen Logging-Aspect nachträglich geloggt wird. Der Code der LoggingAspect Klasse zeigt die Implementierung der Aspects über das PostSharp Framework. Dem Projekt müssen die Referenzen auf die Assemblies “PostSharp.Laos” und “PostSharp.Public” hinzugefügt werden.

    public class Program
    {
        public static int Main(string[] args)
        {
            DoSomething();

            Console.Read();
            return 0;
        }

        [LogAcpect()]
        private static void DoSomething()
        {
            Console.WriteLine("Hello World");
        }
    }

    [Serializable()]
    public class LogAcpect : OnMethodBoundaryAspect
    {
        public override void OnEntry(MethodExecutionEventArgs eventArgs)
        {
            Console.WriteLine("--- Calling: {0} ---", eventArgs.Method);
        }

        public override void OnExit(MethodExecutionEventArgs eventArgs)
        {
            Console.WriteLine("--- Leaving: {0} ---", eventArgs.Method);
        }

        public override void OnSuccess(MethodExecutionEventArgs eventArgs)
        {
            Console.WriteLine("--- Success: {0} ---", eventArgs.Method);
        }

        public override void OnException(MethodExecutionEventArgs eventArgs)
        {
            Console.WriteLine("--- Exception: {0} @ {1} ---", eventArgs.Exception.Message, eventArgs.Method);
        }
    }

An dieser Stelle noch einen paar Hinweise. Die Klasse LogAspect muss als Serializable deklariert werden, ansonsten gibt es beim Starten einen Fehler. Weiterhin ist die Klasse LogAspect eine Attribut-Klasse und kann wie eine solche mit Eigenschaften und überladenen Konstruktoren implementiert werden. Der folgende Code zeigt eine disassemblierte Version der Funktion. Hier sieht man genau, welche Methoden an welcher Stelle aufgerufen werden und das man mittels FlowBehaviour eine Methode kontrolliert abbrechen kann und das eine Exception in der Aspect-Klasse nach “oben” durchgereicht wird.

private static void DoSomething()
{
    MethodExecutionEventArgs ~laosEventArgs~1;
    try
    {
        ~laosEventArgs~1 = new MethodExecutionEventArgs(~PostSharp~Laos~Implementation.~targetMethod~1, null, null);
        ~PostSharp~Laos~Implementation.LogAcpect~1.OnEntry(~laosEventArgs~1);
        if (~laosEventArgs~1.FlowBehavior != FlowBehavior.Return)
        {
            Console.WriteLine("Hello World");
            ~PostSharp~Laos~Implementation.LogAcpect~1.OnSuccess(~laosEventArgs~1);
        }
    }
    catch (Exception ~exception~0)
    {
        ~laosEventArgs~1.Exception = ~exception~0;
        ~PostSharp~Laos~Implementation.LogAcpect~1.OnException(~laosEventArgs~1);
        switch (~laosEventArgs~1.FlowBehavior)
        {
            case FlowBehavior.Continue:
            case FlowBehavior.Return:
                return;
        }
        throw;
    }
    finally
    {
        ~PostSharp~Laos~Implementation.LogAcpect~1.OnExit(~laosEventArgs~1);
    }
}

Die Implementierung eines Security-Aspect hängt von den Bedürfnissen der Applikation ab. In meinem aktuellen Projekt haben wir in einer Datenbank einem Benutzer eine oder mehrere Funktionen zugewiesen. Der SecurityAspect prüft gegen eine IFunctionProvider-Schnittstelle, ob dem Benutzer die entsprechenden Funktion zugeordnet wurde. Die Funktion wird über den Konstruktor der SecurityAspect-Attibutes angegeben. Besteht der Anwender die Sicherheitsabfrage nicht, wird eine SecurityException geworfen. Diese Exception kann mittels Try-Catch abgefangen werden. Eine solche Implementierung stellt sicher, dass Methoden nur dann ausgeführt werden, wenn die Sicherheitsrichtlinien erfüllt werden. Die GUI stellt selbstverständlich a priori sicher, dass eine solche Methode nicht aufgerufen werden kann, wenn der Anwender keine hinreichenden Berechtigungen besitzt.

        [SecurityAcpect(FunctionEnumeration.DoSomething)]
        private static void DoSomething()
        {
            Console.WriteLine("Hello World");
        }

Die aspektorientierte Programmierung ist nur ein Aspekt des Postsharp Frameworks. Die Stärke des Frameworks liegt in der, wie auch immer gearteten, nachträglichen Modifizierung des Codes.