Baugruppenweite Multicast-Attribute. Sind sie böse?

Question

Ich arbeite an einem Projekt, in dem wir mehrere Attribute in AssemblyInfo.cs haben, die zu Methoden einer bestimmten Klasse multicast werden.

[assembly: Repeatable(
AspectPriority = 2,
AttributeTargetAssemblies = "MyNamespace",
AttributeTargetTypes = "MyNamespace.MyClass", 
AttributeTargetMemberAttributes = MulticastAttributes.Public,
AttributeTargetMembers = "*Impl", Prefix = "Cls")]

Was ich daran nicht mag, ist, dass es ein Stück Logik in AssemblyInfo ( Infos wohlgemerkt!), die zunächst einmal überhaupt keine Logik enthalten sollte. Das Schlimmste daran ist, dass die eigentliche MyClass.cs das Attribut nirgendwo in der Datei hat, und es ist völlig unklar, dass Methoden dieser Klasse sie haben könnten. Aus meiner Sicht schadet das der Lesbarkeit des Codes sehr (ganz zu schweigen davon, dass die übermäßige Verwendung von PostSharp die Fehlersuche zu einem Albtraum machen kann), insbesondere wenn man mehrere Multicast-Attribute hat.

Was ist hier die beste Praxis? Ist jemand da draußen ist mit PostSharp Attribute wie diese?

Answer 1

Zunächst möchte ich Max antworten: Aspekte sind in der Tat keine alternativ zu guten OOP-Mustern. Sie sind ein ergänzen . Jeder gute AOP-Entwurf beginnt mit einem guten OOP-Entwurf. Aber OOP-Muster zwingen Sie manchmal dazu, eine Menge Plumbing-Code manuell zu schreiben. In diesen Fällen können Aspekte verwendet werden, um automatisieren die Implementierung des OOP-Musters, pas um sie zu ersetzen.

Wenn Sie AOP intelligent einsetzen, ist Ihre Lösung leichter zu verstehen (der Geschäftscode wird nicht mit dem Wartungscode vermischt), zu testen (Sie können den Aspekt unabhängig vom Geschäftscode testen, d. h. Sie müssen nicht testen, ob eine Geschäftsmethode richtig funktioniert) und zu ändern (Sie müssen nur den Aspekt ändern, wenn Sie das Muster ändern wollen, anstatt jede Implementierung des Musters zu ändern). Wenn Sie nun AOP missbrauchen, wenn Sie es als Hacking-Tool verwenden, wenn Sie nicht vorher in Bezug auf OOP-Muster denken, dann wird Ihnen AOP mehr Kosten als Nutzen bringen. Wie jedes scharfe Werkzeug sollte auch AOP intelligent eingesetzt werden.

Zurück zur ursprünglichen Frage.

Wer sagt Ihnen, dass Sie Aspekte in AssemblyInfo.cs einfügen sollten? Sie könnten eine neue Datei namens GlobalAspects.cs erstellen und alle Aspekte auf Baugruppenebene dort ablegen. Sie haben Recht, dass AssemblyInfo.cs nur für Metadaten auf Baugruppenebene sein sollte.

Aber wie Sie mag ich keine Aspekte auf Montageebene. Ich denke, sie sollten vermieden werden. Das Hauptproblem mit Aspekten auf Baugruppenebene ist, dass sie auf Namenskonventionen beruhen, und das ist ein Übel. (Dieses Übel wird als punktuelle Fragilität in der akademischen AOSD-Gemeinschaft). Wenn Sie nämlich eine Klasse oder einen Namensraum umbenennen, ändern Sie die Menge der Methoden, für die der Aspekt gilt, und das kann schnell zu einem Albtraum werden. Aus diesem Grund verwende ich für mich selbst nie Aspekte, die auf Namenskonventionen basieren.

Wie sieht es mit der Lesbarkeit des Codes aus? Ich denke, lesbarer Code ist zu einem großen Teil kurzer Code. Wenn ich eine Geschäftsmethode namens CreateProduct habe, möchte ich wahrscheinlich nur den Code sehen, der das Produkt erstellt. Die meiste Zeit bin ich nicht an Code interessiert, der Transaktionen, Ausnahmen oder Tracing behandelt. Es reicht mir, wenn ich weiß, dass einige Aspekte das für mich erledigen.

Und woher weiß ich das? Mit PostSharp haben Sie die Visual Studio Extension. Für AspectJ gibt es das AspectJ-Plug-in für Eclipse (AJDT). Sie zeigen Ihnen innerhalb der IDE, welche Aspekte auf den Code angewendet werden, den Sie gerade sehen. Und wenn Sie wirklich Details sehen wollen (was aber selten der Fall ist), können Sie den Debugger verwenden, um in Aspekte einzugreifen, oder Reflector verwenden, um den erzeugten Code zu sehen.

Zusammenfassung:

1. Ein gutes AOP-Design beginnt immer mit einem guten OOP-Design.
2. Vermeiden Sie es, sich bei der Anwendung von Aspekten auf Namenskonventionen zu verlassen.
3. Verwenden Sie die PostSharp-Erweiterung für Visual Studio oder AJDT, um Aspekte in Ihrem Code zu visualisieren.

Answer 2

Ich bin mir sicher, dass dies eine unpopuläre Antwort sein wird, aber vielleicht kann ich meine Gruppenzwang Abzeichen...

Ihr Instinkt ist richtig. Logik in Metadaten jeglicher Art einzubauen ist eine schreckliche, schreckliche Sünde, für die man auf ewig im Höllenfeuer der Unwartbarkeit brennt.

Ich will damit nicht respektlos sein, obwohl ich sicher bin, dass es anders interpretiert werden wird.

Die beste Praxis wäre, keine "aspektorientierten Programmierwerkzeuge" zu verwenden, die Krücken sind, die die Lahmheit schlechter Entwurfs- und Testverfahren ermöglichen. Betrachten Sie stattdessen Ihr Design und fragen Sie sich "warum".

Warum hatte ich das Bedürfnis, dieses Werkzeug? Welches Designproblem wollte ich versuchen zu lösen?

Sobald Sie das Problem verstanden haben, holen Sie Erklärte Entwurfsmuster (Shalloway & Trott) oder Head First Design Patterns (Freeman, Robson, Bates, & Sierra).

Letztendlich ist eine musterorientierte Lösung leichter zu verstehen, leichter zu testen und leichter zu ändern. Die einzigen zusätzlichen Kosten sind die einmalige Gebühr für die Beherrschung von Entwurfsmustern anstelle der wiederkehrenden Kosten für den Versuch, herauszufinden, wo all diese Aspekte sind, wie sie zusammenpassen und wie sie sich gegenseitig beeinflussen, wenn Sie eine Änderung vornehmen.