Diskussion:Markierungsschnittstelle

Überarbeiten: Kritik

Punkt 1 ist nicht so recht nachvollziehbar, denn Vererbung funktioniert schließlich immer so. Deshalb baut man neuerdings ja auch stärker auf flache Hierarchien und "Aggregation statt Vererbung". Kurz: auch bei Schnittstellen ist niemand gezwungen zu erben. Punkt 2 ist nicht ausreichend deutlich. Ja, es geht ein unangenehmer "Geruch" von instanceof aus, allerdings muss man zugestehen, dass dieser schwächer wird, je weiter man sich von der Anwendungsprogrammierung entfernt. Hier sollte man deutlicher werden und die Forderung zur Sparsamkeit erwähnen. Punkt 3 (fehlt bislang) ist die Verlagerung von nachvollziehbarer Logik aus dem regulären Quelltext in Frameworks, die auf der Analyse von Metadaten aufbauen. Ein solcher Exkurs ist für alltägliche Programmieraufgaben meist völlig überzogen. Da jedoch "Tagging" als Technik vertraut erscheint, neigen OO-Anfänger zu diesem Mittel (um die Aufgabe letztlich nur aufzuschieben). Durch den Einsatz von Markierungsschnittstellen entzieht man dem Compiler Möglichkeiten zur statischer Prüfung. Wie steht ihr zur Überarbeitung? Beste Grüße --Uncopy 15:18, 15. Okt. 2009 (CEST)

Zu Punkt 1: Nur weil Vererbung so funktioniert, heisst das nicht, dass das auch immer gut ist ;). Die weitere Verbreitung von flachen Hierarchien entsteht meiner Meinung nach unter anderen aufgrund solcher Unschönheiten.

Im Punkt 1 ist aktuell von einem Mangel die Rede, der nicht ein spezielles Problem von Markierungsschnisstellen ist. Abgeleitete Klassen erben immer die öffentliche(n) Schnittstelle(n) ihrer Vorfahren automatisch mit. Das ist für einige "OOP"-Sprachen lange Zeit die einzige Form gewesen, in der sie eine Ist-Ein-Beziehung ausdrücken ließen (ich nenne mal Turbo-Pascal, das letztlich auch Opfer dieses Mangels wurde, bzw. in Delphi überging, das diesen Mangel nicht hat). Wo immer einmal implementierte Schnittstellen unfreiwillig mitgeerbt werden, ist das m.E. auf Entwurfsfehler des Frameworks(/der Klassenbibliothek) zurückzuführen, nicht auf Entwurfsfehler der Sprache. Aber gut möglich, dass ich dein Problem noch nicht wirklich verstanden habe. --Uncopy 16:27, 24. Nov. 2009 (CET)

Punkt 2: Da kann ich deiner Argumentation bezüglich Entfernung von der Anwendungsprogrammierung nicht ganz folgen; könntest du das noch etwas ausführen für mich?

Ich meinte den Abstand von der Oberfläche, sozusagen die "Tiefe" mit Formulierung als von der Anwendungsprogrammierung entfernt, ich nehme an, das hatte ich etwas umständlich formuliert. --Uncopy 16:27, 24. Nov. 2009 (CET)

Punkt 3: Da bin ich voll und ganz einverstanden. Etwas umformulieren und rein damit.

Gruss -- Bernedom 09:53, 24. Nov. 2009 (CET)

Bedauerlicherweise habe ich hierfür jetzt keine Quellen parat. Was tun?

--Uncopy 16:27, 24. Nov. 2009 (CET) ps: sollten wir die Punkte stärker typografisch ausformen, oder reicht je ein einfacher Absazt?

Ich bin jetzt einfach mal drüber gegangen, sonst friert uns der Artikel noch ein. --Uncopy 17:19, 24. Nov. 2009 (CET)

Zu instanceof: Ich weiß nicht, ob es weniger riecht, aber es geht auch ohne instanceof über überladene Methoden. Beispiel:

interface RandomAccessList extends List, RandomAccess {}

class Foo {
  public void foo(List l) {
    // ...
  }
  public void foo(RandomAccessList l) {
    // ...
  }
}

Letztlich ist es aber äquivalent zu

public void foo(List l) {
  if(l instanceof RandomAccessList) {
  // ...
  } else {
  // ...
  }
}

(Wobei es noch kleinere Unterschiede gibt, etwa dass man beim ersten Beispiel unterschiedliches Javadoc benutzen kann und man anhand der Signaturen sofort erkennt, dass es vermutlich Unterschiede in der Implementierung gibt.)

Zumindest, und das war der Anlass für diesen Kommentar, ist die harte Formulierung „Ein anderes Problem ist die Tatsache, dass zum Erkennen einer Markierungsschnittstelle der Operator instanceof („Instanz von“) verwendet werden muss“ nicht korrekt. – 77.21.172.239 22:28, 14. Apr. 2013 (CEST)