Kann jemand ein Beispiel für aspektorientierte Programmierung (AOP) hochladen, das nicht Protokollierung ist?Aspektorientierte Programmierbeispiele
Ich habe mehrere Ressourcen betrachtet, aber alle Beispiele sind trivial Protokollierung. Wozu ist es nützlich?
Eines der Beispiele, die ausgeliehen direkt von dieser Aspect Oriented Programming: Radical Research in Modularity, Youtube video wurde auf ein Display gemalt. Im Beispiel haben Sie ein Zeichenprogramm, das aus Punkten, Formen usw. besteht, und wenn Änderungen an diesen Objekten auftreten, müssen Sie dem Display mitteilen, dass es sich selbst aktualisieren soll. Ohne es in einem Aspekt zu behandeln, wiederholst du dich ziemlich oft.
AOP, wie ich es verstanden habe, wurde geschaffen, um sich nicht für Querschneidereien zu interessieren, die vielleicht nichts mit Geschäftslogik zu tun haben. Mit Aspekten können Sie diese Anliegen zu Aspekten modularisieren. Eines der Beispiele war das Protokollieren, aber es gibt eine Menge verschiedener Dinge, die Sie am Ende wiederholen könnten. Es entwickelt sich seitdem und es geht nicht mehr um aspektorientierte Programmierung, sondern auch um aspektorientierte Modellierung.
Mehr Informationen über aspektorientierte Programmierung kann aus diesen Quellen zu finden:
Sicherheit - Überprüfen, ob Benutzer vor dem Ausführen bestimmter Methoden über die entsprechenden Berechtigungen verfügen.
Überprüfung der öffentlichen Invariante. Da PostSharp 1.5 mit Aspektvererbung auch über Schnittstellen kommen wird, wird es viele neue Möglichkeiten geben.
Sicherheit
Freundlicher Fehler msgs für asp.net WebControls/webparts
Leistung
Validierung:
[NotNull]
public string Property1 { get; set; }
[Length(Min = 10, Max = 20)]
public string Property2 { get; set; }
[Regex(Expression = @"[abc]{2}")]
public string Property3 { get; set; }
Wo ist de Aspect? Aber Sie könnten einen Ratschlag verwenden, um diese "Anmerkungen" zu lesen, die von einem Joinpoint kommen, der von einem pointcute bereitgestellt wird: * * save (..) So können Sie einen vorherigen Ratschlag verwenden, um zu validieren und fortzufahren Fail-Bedingungen über den ungültigen Zustand. – paulosuzart
Es hängt davon ab, wo die Validierung verwendet wird und welche Art von UI-Framework verwendet wird. Ich verwende nicht die Aspekte von Entitäten, die validiert werden müssen, sondern eher die "defensive Codierung". Ich verwende die Validierung von Entitäten für eine Speichermethode in einem Repository nicht, validiere jedoch irgendwo auf der Benutzeroberfläche. – Paco
@Paco, Das ist nicht wirklich AOP; es ist eher eine kommentierte Programmierung als AOP. In AOP dürfen wir an der aufrufenden Site überhaupt * nichts * angeben. Sogar die Existenz von '[NotNull]' ist in AOP nicht erlaubt. – Pacerier
Design Muster-Implementierung in Java und AspectJ (Hannemann und Kiczales): http://www.cs.ubc.ca/labs/spl/papers/2002/oopsla02-patterns.pdf
Das Papier zeigt, wie einige der Designmuster GoF in einer besseren Art und Weise in Java AspectJ mit implementiert können
Sie können keine Mehrfachvererbung in Java haben. Durch die Verwendung von AOP können Sie jedoch die Mehrfachvererbung "beschränken". Versuchen Sie, dies zu googlen, um einige Beispiele zu sehen.
Ich stimme auch mit Eyvid. Hannemann und Kiczales Papier eignet sich hervorragend, um die Grundlagen zu Designmustern zu erlernen und einige großartige AOP-Beispiele zu erhalten.
My photo album verwendet aspectj für drei Dinge:
Die erste, insbesondere ziemlich direkt aus einem google tech talk on AOP war. Es geht um Modularität in einer anderen Art und Weise als die meisten Leute denken. Auf jeden Fall empfehlen, das zu beobachten, wenn Sie daran interessiert sind, wie man es für immer nutzt.
Ein anderes klassisches Beispiel (wie Protokollierung) ist Caching. Aber andere Beispiele sind interessanter.
Rückgängig - Ich rufe eine Drittanbieter-Assembly auf, die Operationen zum Rückgängigmachen unterstützt. Es erfordert Anrufer, einen Rückgängig-Kontext zu erstellen, einige Methoden in der Assembly aufzurufen, und dann den Undo-Kontext zu zerstören. Kontexte können verschachtelt werden. Wenn ein Kontext erstellt wird, aber in einem unerwünschten Zustand verbleibt, der einen App-Neustart erfordert.
Normalerweise rückgängig verwenden ich so etwas wie dieses
void foo()
{
int id = lib.create_undo_context();
try
{
lib.performsomeaction();
lib.performsomeaction();
lib.performsomeaction();
}
finally
{
lib.destroy_undo_context(id);
}
}
mit Postsharp schreiben würde ich ein Attribut namens [Rückgängig], die definieren, erstellt die Undo-Kontext, wenn die Methode beginnt und zerstört es, wenn das Verfahren beendet (auch wenn eine Ausnahme ausgelöst) - so sieht der Code wie diese
[Undo]
void foo()
{
lib.performsomeaction();
lib.performsomeaction();
lib.performsomeaction();
}
Es ist ein wenig komplizierter, diese zu implementieren, als ich zeigen werde, weil ich sicherstellen, daß alle rückgängig machen Kontexte selbst in Fällen, gereinigt, wo es verschachtelt Undo Kontexte - aber du bekomme eine Vorstellung.
Transaktionsverwaltung.
Meiner Meinung nach möchten Sie nicht, dass Objekte, die Teil einer Transaktion sein können, sich bewusst sind, dass sie sich in einer Transaktion befinden. Mit Hilfe von AOP können Sie Objekte nach Bedarf in Transaktionen zusammenfassen, ohne dass die Objekte in der Transaktion sich entweder der Tatsache bewusst sein müssen, dass sie sich in einer Transaktion befinden, oder sogar des Vorhandenseins des AOP-Frameworks.
Ich habe aspektorientierte Programmierung verwendet, um eine Keyword-Suchmaschine zu implementieren. Es war mehr wie ein Experiment, aber es zeigt, wie AOP für andere Zwecke als Protokollierung und Verfolgung verwendet werden kann.
Grundsätzlich gilt:
(i) Der Benutzer des Motors markiert seine/ihre Klassen als KeywordSearchable,
(ii) Der Motor startet die Schaffung & Zerstörung dieser KeywordSearchable Instanzen Tracking,
(iii) Die Motor-Extrakte die Schlüsselwörter aus diesenSearchSearchable-Objekten,
(iv) Bei den Objekten und den Schlüsselwörtern sorgt der Algorithmus für die Suche.
Weitere Informationen hierzu finden Sie unter http://montrealistic.blogspot.com/2011/08/aspect-oriented-implementation-of.html.
Dependency Injection
Streng genommen Dependency Injection ist nichts anderes als ein Ablängen Sorge. Viele Dependency Injection-Frameworks verwenden, um eine attributbasierte Programmierstil wie folgt aus:
public class Car:IDisposable
{
[Inject]
public IGearBox Gearbox { get; set; }
...
}
Das [Inject] Attribut auch als ein Aspekt ohne Abhängigkeit zu einem externen Rahmen entworfen könnte.
Beispiele für AOP:
wir uns vor, Sie eine Mitteilung nach innen Methoden Ihrer Domänenmodell protokollieren möchten:
Beispiel: Protokollierung ohne AOP:
namespace Examples\Forum\Domain\Model;
class Forum {
/**
* @Flow\Inject
* @var \Examples\Forum\Logger\ApplicationLoggerInterface
*/
protected $applicationLogger;
/**
* Delete a forum post and log operation
*
* @param \Examples\Forum\Domain\Model\Post $post
* @return void
*/
public function deletePost(Post $post) {
$this->applicationLogger->log('Removing post ' . $post->getTitle(), LOG_INFO);
$this->posts->remove($post);
}
}
Wenn Sie diese in vielen Orten zu tun haben, Die Protokollierung würde ein Teil Ihrer Domänenmodelllogik werden. Sie müssten alle Protokollabhängigkeiten in Ihre Modelle injizieren. Da Protokollierung nichts ist, was ein Domänenmodell interessieren sollte, ist dies ein Beispiel für eine nicht-funktionale Anforderung und ein sogenanntes Cross-Cutting-Anliegen.
Mit AOP würde der Code in Ihrem Modell nichts über die Protokollierung wissen. Es wird sich nur auf die Geschäftslogik konzentrieren.
AOP ist fehleranfällig, da keine Änderungen lokalisiert werden. Es sind im Grunde Annotationen ohne Annotation (auch unsichtbare Annotationen). Siehe auch https://pp.info.uni-karlsruhe.de/uploads/publikationen/constantinides04eiwas.pdf – Pacerier
@Pacerier: Ihre Aussage ist falsch. Ich verwende AOP seit Jahren, um Fehler zu vermeiden und Refactoring und Debugging zu vereinfachen. Der gesamte cross-cutende Code, der in OOP mit der gesamten Codebasis verwoben ist, ist ordentlich modularisiert und somit leicht in AOP zu lokalisieren. Core-Code ist einfacher zu lesen und zu pflegen. Aussagen wie die Ihre werden meistens von Leuten gehört, die das Konzept von AOP nicht verstanden und es nicht ausgiebig benutzt haben (außer Geben ist ein kurzer Versuch, der einfach nicht genug ist). – kriegaex
@kriegaex, Wann genau das Konzept von AOP gekommen ist. – Ali786