Brechen Ereignisse Schnittstellen?

Question

Hinweis: In dieser Frage geht es um formale Schnittstellen (z. B. public interface IButton {...} ).

Ich bin ein Actionscript-Entwickler, aber ich vermute, dass meine Frage in vielen Sprachen, die sowohl formale Schnittstellen als auch Ereignisse zulassen, eine Rolle spielen wird.

Ich liebe Schnittstellen. Ich liebe die Trennung zwischen Schnittstelle und Implementierung. (Ich wünschte, Actionscript würde jede Klasse dazu zwingen, eine formale Schnittstelle zu implementieren, so wie es Objective-C tut.) Alle meine Klassen implementieren eine Schnittstelle (oder mehrere), und Sie werden mich nie dabei erwischen, wie ich eine öffentliche Methode schreibe, die nicht in einer Schnittstelle referenziert ist.

Aber Actionscript ist auch stark von Events abhängig. Mein Problem ist folgendes: Jeder Teil einer Klasse, der mit externen Klassen oder Prozessen kommuniziert, ist Teil ihrer Schnittstelle (oder sollte es sein). (Mir ist klar, dass dies eine Frage der Meinung ist. Wenn Sie anderer Meinung sind, wird diese Frage für Sie wahrscheinlich bedeutungslos sein).

Es gibt mehrere Möglichkeiten, dieses klare Bild zu trüben, aber die meisten davon sind vermeidbar:

1. Sie können keine öffentlichen Eigenschaften in einer Schnittstelle auflisten. Lösung: Verwenden Sie keine öffentlichen Eigenschaften in Ihren Klassen. Verwenden Sie stattdessen Getter und Setter (ich bin auch nicht gerade verrückt nach ihnen, aber ich verwende sie, wenn ich muss).

2. Wenn Klassen kommunizieren, indem sie Argumente an Konstruktoren übergeben, gehen diese Nachrichten an den Schnittstellen vorbei, da man eine Konstruktorfunktion nicht in einer Schnittstelle auflisten kann. Ich vermeide dieses Problem, indem ich (fast) nie Parameter durch Konstruktoren übergebe. Ich bevorzuge init()-Methoden, die in Interfaces explizit gemacht werden können.

3. Klassen können öffentliche Methoden haben, die nicht in einer Schnittstelle aufgeführt sind. Ich vermeide dies, indem ich es nicht tue. Meine Klassen implementieren Interfaces. Diese Interfaces enthalten Header für ALLE öffentlichen Methoden.

4. Viele Klassen versenden Ereignisse.

Der letzte Punkt ist der Knaller.

Nehmen wir an, ich gebe Ihnen eine Klasse mit dem Namen Blah und Sie fragen mich, wie man sie benutzt. Ich kann Ihnen sagen: "Sie implementiert die IBlah-Schnittstelle. Schauen Sie sich das an und Sie werden sehen, was Sie alles mit Blah machen können."

Außer Blah erweitert EventDispatcher, was bedeutet, dass es Ereignisse versendet.

"Welche Ereignisse sind damit verbunden?" fragen Sie.

"Äh..."

Um das herauszufinden, müssen Sie die JavaDoc oder den Quellcode von Blah durchlesen. Beides sollten Sie nicht tun müssen! Sie sollten in der Lage sein zu wissen, wie Sie mit einer Klasse interagieren können, indem Sie ihre Schnittstelle(n) überprüfen.

Ich wünschte, die Schnittstellen könnten so aussehen:

public interface IBlah
{
    function foo() : void;
    function bar() : Boolean;
    event BlahEvent;
}

Sie können jedoch keine Ereignisse in einer Schnittstelle angeben.

Liege ich richtig, dass Ereignisse Schnittstellen unterbrechen? Für mich ist das so, als würde ich Ihnen ein Auto geben und sagen, hier ist die Bedienungsanleitung. Im Handbuch wird angeblich alles erklärt, was auf dem Armaturenbrett steht. Aber dann, wenn du das Auto fährst, erscheinen seltsame Dohickies und es ertönen seltsame Geräusche - Ereignisse, die nicht im Handbuch erwähnt werden.

Wenn ich falsch liege, erklären Sie mir das bitte.

Wenn ich richtig liege, gibt es eine gute Möglichkeit, das Problem zu vermeiden?