Peter Bucher - Mein Experiment, meine Spielereien, meine Welt...   ·   Stefan Falz   ·   Jürgen Gutsch   ·   Golo Roden   ·   ASP.NET Zone   ·   Microsoft ASP.NET
Willkommen bei ASP.NET Zone. Anmelden | Registrieren | Hilfe

Sinn und Zweck von AOP

Am 13. Oktober 2008 haben Golo Roden und ich unter dem Titel Noch Fragen, Roden? Ja, Bucher! angekündigt, jeweils zum ersten eines jeden Monats einen Kommentar zu einem vorab gemeinsam gewählten Thema verfassen zu wollen. Bisher sind in dieser Reihe folgende Kommentare erschienen:

Heute, am 1. März 2009, ist es nun wieder so weit, und unser Thema für diesen Monat lautet:

Sinn und Zweck von AOP


So wohl Golo wie auch ich haben uns unabhängig voneinander im Vorfeld unsere Gedanken gemacht, wie wir diesem Thema gegenüberstehen. Golos Kommentar findet sich zeitgleich in seinem Blog, folgend nun mein Kommentar zu diesem Thema:

AOP?

Schon wieder so ein neues Akronym aus der technischen Welt.
Doch was hat es damit auf sich und worin liegt der Sinn des ganzen?

Angefangen, bei 0…

Was ist ein Aspekt?

Aspekt ist als Ansicht oder Anblick definiert, also eine Ansicht oder einen Anblick auf etwas.

…zu 1…

Was hat das mit Programmierung zu tun?

AOP bedeutet Aspektorientierte Programmierung und stellt ein Paradigma dar, also ein Prinzip nach dem vorgegangen und entwickelt wird.

…zu 0

Wieso brauchen wir überhaupt etwas neues?

Ich denke die Frage nach dem Sinn lässt sich klären, indem die Probleme aufgegriffen werden, die das wie bei den Erfindern ausgelöst haben.

Es gibt bei der Entwicklung von Software viele Gebiete die auf irgend eine Weise in Module gekapselt werden können.

Wie wir wissen, wird schon seit langer Zeit modular entwickelt. Zuerst nur mit einer Abstrahierung auf Funktionsebene und später auch auf Ebene eines Objektes das beliebige Daten / Funktionen enthalten konnte. (Siehe Programmierparadigma Definitionen)

Da gibt es beispielsweise eine Bibliothek für die Benutzerverwaltung, ein Modul für die Anbindung an irgend eine Schnittstelle und ganz viel Clientcode (Der Bibliotheken nutzt), der eine bzw. mehere Funktionen abbildet.

Irgendwo daneben oder dazwischen befinden sich auch Bereiche die sich nicht ohne weiteres kapseln oder in Module aufteilen lassen.

Beispielsweise:

  • Viele Methoden brauchen eine Prüfung all ihrer Parameter auf bestimmte Einschränkungen, ansonsten darf der Programmcode nicht mehr ablaufen.
  • Logging oder Tracing bei Methodenaufrufen um bspw. die Reihenfolge später nachvollziehen zu können.
  • Sicherheitsprüfungen auf bestimmten Methoden.
  • Methodenbasiertes Caching.

Es gibt noch viel mehr solche Aufgaben, die wir als Entwickler zu bewältigen haben und überall verstreut – also in jeglichen Modulen – gleichzeitig auftreten.

Sowas nennt sich in der Informatik Cross-Cutting Concern, also Aufgaben die zwangsweise auf viele verschiedene Module verteilt sind und sich nicht einfach so aufsplitten lassen.

Teilweise erreicht man auch in solchen Fällen eine Modularisierung mithilfe von Helper Klassen, jedoch nie mit einem so hohen Gewinn an Code und Verdoppelung wie das zu wünschen wäre.

…wieder zu 1.

Aspektorientiert entwickeln

Wie wäre es, wenn wir ein Modul entwickeln könnte, dass mit verschiedenen Parametern initialisiert werden kann und Zugriff auf Punkte im eigenen Code hat?

Es wird ein Aspekt entwickelt, der nur seine Aufgabe erfüllt und den Code der Zielmethode nicht kennt.
Es wird eine Methode entwickelt (Clientcode) der nur seine Aufgabe erfüllt und den Code des Aspekts nicht kennt, sowie auch dessen Auswirkungen nicht.

Ein Aspekt repräsentiert sich als eine Klasse die von einer Basisklasse eines AOP-Frameworks ableitet.
Diese Basisklasse eines AOP-Frameworks bietet dann Methoden an um sich an bestimmte Punkte vom Funktionscode – also unserem normalem Code – einzuhängen.

Dabei kann der Aspekt selber einfach nur Code ausführen, die Rückgabewerte von Methoden auswerten oder gar verändern und vieles mehr.

Anschliessend ein Beispiel:

Gemeinsamer Code:

public enum Role {
    Guest = 0,
    User = 1,
    Editor = 2,
    Admin = 3
}

Ohne AOP:
public class Window {
    public void ShowSomething() {
        if(AppContext.CurrentRole >= Role.User) {
             // TODO: Show something.             
        } else {
            throw new SecurityException(“Curent Role not allowed.”);
        }
    }
    public void DeleteFoo(Guid bar) {
        if(AppContext.CurrentRole >= Role.Admin) {
             // TODO: Delete something.
        } else {
            throw new SecurityException(“Curent Role not allowed.”);
        }
    }
}

Dasselbe mit AOP:

public class AuthorizationAspect : OnXYZAspect {
    private Role _allowedRole = Role.Guest;
    
    public AuthorizationAspect(Role allowedRole) {
        _allowedRole = allowedRole;
    }
    
    protected override OnMethodExecution(object sender, MethodExecutionEventArgs e) {
        if(AppContext.CurrentRole < _allowedRole) {
             throw new SecurityException(“Curent Role not allowed.”);
        }
    }
}
public class Window {
    [AuthorizationAspect(Role.User)]
    public void ShowSomething() {
        // TODO: Show something.
    }
    [AuthorizationAspect(Role.Admin)]
    public void DeleteFoo(Guid bar) {
        // TODO: Show something.
    }
}

Beispielhafte Nutzung (Gilt für beide Varianten):

 
// Benutzer loggt sich ein, AppContext wird auf eine Rolle gesetzt.
Window window = new Window();
try {
    window.ShowSomething();
} catch(SecurityException e) {
    MessageBox.Show(“Permission denied”);
}

Wie man sieht, wir die gemeinsame Logik für die Abarbeitung einer Sicherheitsabfrage in einer neuen Klasse gekapselt. Damit spart es doppelten Code in mehreren Klassen.

Trotzdem müssen Aspekte und Mitglieder einer Klasse oder sie selbst irgendwie mit dem Aspekt verkünpft werden. Dies geschieht mit der Dekleration eines Attributes.

Dabei können auch Parameter übergeben werden, die dann innerhalb eines Aspektes nutzbar sind.

Abschliessend noch ein paar Vor- und Nachteile die mir ersichtlich sind.

Es gibt noch viel zu sagen, aber dafür reicht die Zeit nicht, oder: Fazit :)

Ich finde die Aspektorientierte Programmierung eine sehr interessante Entwicklung, die aber Vorteile sowie auch Nachteile in sich birgt.
Es gibt viele weitere Details nach denen geforscht werden kann. So gibt es verschiedene Frameworks für .NET die AOP ermöglichen und dies auf unterschiedlichen Ebenen und Arten ermöglichen.

Es ist möglich Code zur Laufzeit zu einer Einheit zu verschmelzen (Weaving / weben), sowie es auch möglich ist, dies zur Kompilezeit zu tun. Beides hat wiederum Vor- sowie Nachteile.

Für viele Aufgaben reicht die prozedurale bzw. objektorientierte Programmierung aus und für viele Aufgaben ist AOP gar nicht geeignet oder zu oversized.
Auch gibt es immer noch das Problem dass es keine native Möglichkeit gibt, AOP einzusetzen. Man ist also auf bestehende Frameworks, derer Weiterentwicklung und Generierung von nicht optimalem Code angewiesen.

Trotzdem empfehle ich dieses Paradigma unbedingt anzuschauen und wo sinnvoll auch zu nutzen.
Aber wo auch immer diese Technik keine Vorteile oder gar mehr Nachteile als Vorteile bringt, fährt man konventionell immer besser.

Ein Beispiel wäre folgendes:

< Datenschicht >
           |
<Geschäftsschicht>
           |
<Clientcode>

Per Interface wird eine Schnittstelle von der Daten- zur Funktionsschicht beschrieben.
Mehrere Datenklassen implementieren dieses Interface. Die Geschäftsschicht nutzt das Interface um Daten abzurufen und zu manipulieren.

Wenn jetzt ein Caching eingebaut werden soll, kann dies einfach in der Geschäftsschicht implementiert werden, anstelle in jeder einzelnen Implementierung der Datenschicht. AOP ist m.E. also nicht nötig und bringt auch keine Vorteile.

Vorteile:

  • Übersichtlicherer Funktionscode
  • Trennung der Aspekte vom Clientcode (Modularisierung zur Entwurfszeit)
  • Vermeidung von doppeltem Code (Einhaltung des DRY-Prinzips)
  • […]

Nachteile:

  • Leistungsverlust bei Weaving zur Laufzeit
  • Codeoverhead durch ein AOP-Framework (vs. eigener Code)
  • Schlechtere Nachvollziebarkeit bei Fehlverhalten, da der Code getrennt ist
  • Ggf. Wechselwirkungen bei der Verwendung von mehreren Aspekten auf einer Methode (Reihenfolge beachten).
  • […]

 

…und bei 100% angekommen, EOF.

Veröffentlicht Sonntag, 1. März 2009 09:37 von Peter Bucher

Kommentare

# Sinn und Zweck von AOP

Sinn und Zweck von AOP

Dienstag, 3. März 2009 07:46 by goloroden.de

# Interfaces vs abstrakte Klassen

Am 13. Oktober 2008 haben Golo Roden und ich unter dem Titel Noch Fragen, Golo? Ja, Bucher! angekündigt,

Dienstag, 14. April 2009 22:50 by Peter Bucher

# Woran erkennt man einen guten Entwickler?

Am 13. Oktober 2008 haben Golo Roden und ich unter dem Titel Noch Fragen, Golo? Ja, Bucher! angekündigt,

Freitag, 1. Mai 2009 14:09 by Peter Bucher

# Primärschlüssel: GUID vs Identity

Am 13. Oktober 2008 haben Golo Roden und ich unter dem Titel Noch Fragen, Golo? Ja, Bucher! angekündigt,

Donnerstag, 2. Juli 2009 22:38 by Peter Bucher

# C# oder VB: Welche Sprache soll ich lernen?

Am 13. Oktober 2008 haben Golo Roden und ich unter dem Titel Noch Fragen, Golo? Ja, Bucher! angekündigt,

Montag, 3. August 2009 19:04 by Peter Bucher

# Alles var – oder nicht?

Am 13. Oktober 2008 haben Golo Roden und ich unter dem Titel Noch Fragen, Golo? Ja, Bucher! angekündigt,

Dienstag, 1. September 2009 09:48 by Peter Bucher

# Heisst die Zukunft RIA?

Am 13. Oktober 2008 haben Golo Roden und ich unter dem Titel Noch Fragen, Roden? Ja, Bucher! angekündigt,

Donnerstag, 15. Oktober 2009 18:33 by Peter Bucher

# Wieviel Sinn machen Unittests?

Am 13. Oktober 2008 haben Golo Roden und ich unter dem Titel Noch Fragen, Golo? Ja, Bucher! angekündigt,

Montag, 2. November 2009 09:43 by Peter Bucher

# Reflection – Fluch oder Segen?

Am 13. Oktober 2008 haben Golo Roden und ich unter dem Titel Noch Fragen, Roden? Ja, Bucher! angekündigt,

Dienstag, 1. Dezember 2009 21:03 by Peter Bucher

# this oder kein this

Am 13. Oktober 2008 haben Golo Roden und ich unter dem Titel Noch Fragen, Roden? Ja, Bucher! angekündigt,

Dienstag, 16. Februar 2010 21:30 by Peter Bucher

# Felder vs Eigenschaften

Am 13. Oktober 2008 haben Golo Roden und ich unter dem Titel Noch Fragen, Roden? Ja, Bucher! angekündigt,

Sonntag, 14. März 2010 16:53 by Peter Bucher

# Abstraktion

Am 13. Oktober 2008 haben Golo Roden und ich unter dem Titel Noch Fragen, Roden? Ja, Bucher! angekündigt,

Freitag, 9. April 2010 13:22 by Peter Bucher
Anonyme Kommentare sind nicht zugelassen