Sind Tag- (oder "Marker"-) Schnittstellen veraltet?

Question

Ich versuche, einem Kollegen dabei zu helfen, mit OO zurechtzukommen, und stelle fest, dass es in einigen Fällen schwierig ist, solide Beispiele aus der Praxis für das Konzept eines Tags zu finden (oder Markierung ) Schnittstelle. (Eine Schnittstelle, die keine Methoden enthält; sie wird nur als Tag oder Marker oder Label verwendet). Obwohl es für unsere Diskussionen eigentlich keine Rolle spielen sollte, verwenden wir PHP als Plattform für die Diskussionen (weil es eine gemeinsame Sprache für uns ist). Ich bin wahrscheinlich nicht die beste Person, um OO zu lehren, da der Großteil meines Hintergrunds sehr theoretisch und etwa 15 Jahre alt ist, aber ich bin, was er hat.

Auf jeden Fall führt der Mangel an Diskussionen, die ich über Tag-Schnittstellen gefunden habe, zu der Annahme, dass sie nicht einmal ausreichend genutzt werden, um eine Diskussion zu rechtfertigen. Liege ich hier falsch?

Answer 1

In Java werden Tag-Schnittstellen verwendet (Serializable ist das offensichtliche Beispiel). C# und sogar Java scheinen sich davon wegzubewegen, aber zugunsten von Attributen, die das Gleiche erreichen können, aber auch viel mehr tun.

Ich denke immer noch, dass es einen Platz für sie in anderen Sprachen gibt, die nicht das Attributkonzept haben, das .NET und Java haben.

ETA:

Normalerweise verwenden Sie dies, wenn Sie eine Schnittstelle haben, die eine Implementierung impliziert, aber Sie wollen nicht, dass die Klasse, die die Schnittstelle implementiert, diese Implementierung tatsächlich bereitstellen muss.

Einige Beispiele aus der Praxis:

Serializable ist ein gutes Beispiel - es impliziert, dass es (irgendwo) eine Implementierung gibt, die die Objektdaten serialisieren kann, aber da eine generische Implementierung dafür zur Verfügung steht, besteht keine Notwendigkeit, dass das Objekt diese Funktionalität selbst implementiert.

Ein anderes Beispiel wäre ein System zur Zwischenspeicherung von Webseiten. Angenommen, Sie haben ein "Page"-Objekt und ein "RequestHandler"-Objekt. Der RequestHandler nimmt eine Anforderung für eine Seite entgegen, sucht/erzeugt das entsprechende Page-Objekt, ruft eine Render()-Methode für das Page-Objekt auf und sendet die Ergebnisse an den Browser.

Nehmen wir an, Sie wollten eine Zwischenspeicherung für gerenderte Seiten implementieren. Das Problem ist jedoch, dass einige Seiten dynamisch sind und daher nicht gecached werden können. Eine Möglichkeit, dies zu implementieren, bestünde darin, dass die cachefähigen Page-Objekte eine ICacheable "tag"-Schnittstelle implementieren (oder umgekehrt, man könnte eine INotCacheable-Schnittstelle haben). Der RequestHandler würde dann prüfen, ob die Seite ICacheable implementiert hat, und wenn ja, würde er die Ergebnisse nach dem Aufruf von Render() zwischenspeichern und diese zwischengespeicherten Ergebnisse bei nachfolgenden Anfragen für diese Seite ausgeben.

Answer 2

In .Net können Tag-Schnittstellen hervorragend für die Verwendung mit Reflection- und Erweiterungsmethoden geeignet sein. Tag-Schnittstellen sind typischerweise Schnittstellen ohne jegliche Methoden. Sie ermöglichen es Ihnen, zu sehen, ob ein Objekt von einem bestimmten Typ ist, ohne dass Sie das Risiko eingehen müssen, Ihre Objekte zu reflektieren.

Ein Beispiel aus dem .Net Framework INamingContainer ist Teil von ASP.Net

Answer 3

Ich würde mich selbst als OO-Programmierer bezeichnen, und ich habe noch nie von einer Tag-Schnittstelle gehört.

Answer 4

Ich denke, Tag-Schnittstellen sind es wert, diskutiert zu werden, weil sie einen interessanten Eckfall des Konzepts einer Schnittstelle darstellen. Ihre seltene Verwendung ist auch Aber es lohnt sich, darauf hinzuweisen!

Answer 5

Ich habe ein paar Mal Tag-Schnittstellen in einem Objektmodell verwendet, das eine SQL-Datenbank darstellt. In diesen Fällen handelt es sich um einen Subtyp der Root-Schnittstelle für bestimmte Objekttypen. Es ist einfacher, nach einem Tag-Interface zu suchen als nach einem Attribut ('obj is IInterface', anstatt Reflection zu verwenden)