[Erledigt] Marker-Interfaces

[Kagu-chan]

Es gibt außerdem noch eine (un-)art von Interfaces ( was aber nicht bedeutet das sie worst practice sind ): Marker-Interfaces; die definieren genau 0 Methoden und 0 Konstanten.

Hallo, beim lesen der beiträge bin ich über das oben gepostete Zitat gestolpert.
Hab mal gegooglet, was es ist, aber werd nicht ganz schlau daraus.

Hat jemand eine Erklärung was das ist oder ein sinnvolles Anwendungsbeispiel?
Wozu Interfaces dienen, weiß ich, aber Marker-Interfaces... sehen mir grad irgendwie wastet aus... O.o

LG
Kagu

[rkr]

Zugegeben blödes Beispiel:

WriteStream und ReadStream können beide vom Stream ableiten, wobei ein Stream dann keine eignenen Methoden haben muss. Das kann dann sinnvoll sein, wenn man in der konsumierenden Klasse mit "instanceof" unterscheiden will, was es ist, als Typehint dann aber beides erlauben will.

Ich bin mir sicher, dass es auch gute Beispiele gibt

[ApoY2k]

Serializable bei Java ist wohl das bekannteste Beispiel.

The serialization interface has no methods or fields and serves only to identify the semantics of being serializable.

Das Interface hat keine Methoden, muss aber zwingend benutzt werden, wenn man Klassen als serialisierbar markieren will. Intern erledigt das dann die JVM unter der Haube. Alles was sie braucht, ist die Markierung.

[mYkon]

Marker-Interfaces:

Du "markierst" z.B. eine Klasse mit dem Interface Cachable. Dein Cache-Service cached somit alle Objekte, die dieses Interface implementieren. Das Interface schreibt aber ansonsten nix vor, weil das Objekt per se z.B. mit serialize schon gecached werden kann.

Somit wurde es bloss markiert.

[Kagu-chan]

Ich sage dem programm also nur "theoretisch ist xy möglich" - oder verstehe ich da immer nochwas falsch?

[rkr]

Ja. Klasse ist vom Typ XY - manche Interfaces haben dann noch magische Fähigkeiten. Du kannst das Prinzip auch benutzen, um Klassen für bestimmte Umgebungen zuzulassen. Das "Controller"-Interface kannst du Klassen geben, die in deiner App als "Controller" auftreten sollen. So kann man in einer Classregistry sagen "hier sollen nur Controller rein" - ohne dabei fest vorzuschreiben, wie Controller genau aussehen müssen.

Keine Ahnung, ob das eine "Unart" ist...

[mYkon]

Nein. Theoretisch ist gar nix möglich. Weil die Klasse nichts kann. Aber du kannst trotzdem anderen Komponenten etwas mitteilen. "Ich würde gerne gecached werden", "Ich würde gerne per ACL geschützt werden" usw.

[Kagu-chan]

Mhm... ich lass mir das ganze nochmal durch den Kopf gehen und melde mich einfach bei weiteren Fragen.

Danke (:

[nikosch]

"Ich würde gerne gecached werden", "Ich würde gerne per ACL geschützt werden" usw.

Auf den ersten Blick scheint mir diese Aussage falsch zu sein. Ein Objekt sollte nichts wissen dürfen, wozu/wie es genutzt wird, deshalb sollte das Interface etwas über das Objekt aussagen (was es kann), nicht über den Nutzungskontext (wozu es genutzt wird).

[Kagu-chan]

Das ist natürlich ein Argument... aber ich denke ich hab es soweit verstanden, das ich was mit anfangen kann ^⁻^

[mYkon]

Ein Objekt sollte nichts wissen dürfen, wozu/wie es genutzt wird, deshalb sollte das Interface etwas über das Objekt aussagen (was es kann), nicht über den Nutzungskontext (wozu es genutzt wird).

Das wäre in meinen Augen der normale Ansatz eines Interfaces ja. Bei einem MarkerInterface kann das Objekt per se aber nichts. Deshalb ist es nur für den Nutzungskontext interessant.

[rkr]

Auf den ersten Blick scheint mir diese Aussage falsch zu sein. Ein Objekt sollte nichts wissen dürfen, wozu/wie es genutzt wird, deshalb sollte das Interface etwas über das Objekt aussagen (was es kann), nicht über den Nutzungskontext (wozu es genutzt wird).

Primär eigentlich "was es ist".[/klugshice]

[mYkon]

Ein Beispiel noch: Ein "ProtectedByAclInterface" extended ein "EntityInterface" z.B. (getId() vorgeschrieben)

ProtectedByAclInterface = MarkerInterface für Security Komponente: Aha da kommt was, was ich schützen sollte. Rest wird ignoriert.

Mein Satz dazu: "Ich würde gerne per ACL geschützt werden".

[tr0y]

Die simpelste aber einleuchtenste Version des Marker Interface ist die Verhaltensbeschreibung.

Stell dir Folgendes Szenario vor:

interface Container
{
   public function __construct(array $items = []);
   public function has($item);
   public function get($item);
   public function set($item, $content);
   public function remove($item);
} 

Ein simples Container Interface das vorgibt das der Container 4 Methoden und einen Constructor haben soll.

Nun möchtest du spezifizieren das es Mutable und Immutable Container gibt ( veränderbare und unveränderbare ):

interface ImmutableContainer extends Container {}
interface MutableContainer extends Container {} 

Diese Beiden Interfaces fungieren als Marker-Interfaces, da sie das Verhalten des Containers als veränderbar oder unveränderbar beschreiben. Du markierst hier nur den Container statt 2 separate Container-Interfaces aufzubauen bei dem der ImmutableContainer bspw. kein Remove() kennt und kein set(). Beide Container können jederzeit als "Container" identifiziert werden und das sie entsprechende Container-Methoden besitzen. Es ist aber auch möglich festzustellen ob der Container veränderbar oder unveränderbar ist.

Auch der PHP-Core nutzt Marker-Interfaces ( sie werden zwar als Interne Interfaces definiert und nicht explizit als solche beschrieben aber es sind reguläre Marker-Interfaces ). Bspw.: [man]Traversable[/man] auch hier wird eine Verhaltensbeschreibung gegeben ohne Methoden zu definieren.

[mYkon]

Wobei ich noch anmerken möchte, dass ein __construct in einem Interface nur gaaaaanz selten was verloren hat, oder?