> Der Hauptanwendungszweck von Interfaces ist, den Nutzer einer Klasse von ihrer tatsächlichen Implementierung zu trennen. Er sieht nur das Interface, und wie es implementiert ist, hat ihn nicht zu interessieren. Das Interface stellt den Kontrakt dar, der bereitgestellt wird und den ich nutzen kann. Durch die Trennung zwischen Kontrakt und Ausführung des Kontrakts entsteht Austauschbarkeit und insbesondere die Möglichkeit zum Mocken und Unit-Testen. Statische Typchecks sind nur ein Aspekt des Ganzen. Sie sind **der** Aspekt von Interfaces. Den gesamten Rest, den du beschreibst, darft du Polymorphie zu Gute rechnen. In Java sind Interfaces eben eine Möglichkeit Polymorphie zu realisieren. > Sowas geht nur mit Interfaces (oder, ja, abstrakten Superklassen, die ich wie Interfaces nutze). Gibt es dafür einen triftigen Grund? Vertikale Komposition, also Vererbung, sorgt für eine stärkere Kopplung der beteiligten Klassen als horizontale Komposition (durch Interfaces, Traits, Mixins...). Bei sehr kohärenten Zusammenhängen, kann man das machen. Im allgemeinen Fall würde ich zunächst davor zurückweichen. Und wie soll das in Sprachen ohne multipler Vererbung funktionieren? > In Sprachen wie PHP oder JavaScript kann man Interfaces tatsächlich auf ein technisches Muster für vorhandene Klassenelemente reduzieren, weil die Bindung Aufruf->Implementierung zur Laufzeit erfolgt. Womit wir wieder bei der Polymorphie wären. Diesmal durch Duck-Typing. > PHP hat weder diese duale Darstellung von Data- und Accessor-Properties, noch den get/set Syntaxzucker. Wenn ich in ein PHP Interface eine Eigenschaft schreibe, bedeutet das zur Laufzeit den direkten Zugriff auf ein Field. Und DAS ist ein Problem, weil ich ein Field nicht mocken oder nach Bedarf durch einen Methode substituieren kann. In PHP gibt es die "magischen" __get- und __set-Methoden, damit kannst du Zugriff auf Eigenschaften regeln. Dein Argument mit dem Mock kann ich nicht nachvollziehen. Wieso solltest du Abhängigkeiten von Eigenschaften nicht auflösen können? Das Interface würde ja nur die Existenz und den Typen der Eigenschaft festlegen. Ich glaube, dass dieses Problem gar nicht existiert, aber selbst wenn, würde ich sagen, dass man in einem solchen Fall die Eigenschaft eben nicht per Interface erfordern sollte. Man verliert ja durch die Möglichkeit nichts. Man gewinnt nur Einfachheit, Konsistenz und Ausdrucksmöglichkeit hinzu. > Deswegen muss ich in PHP, genau wie in Java, ein interfacefähiges Property durch explizite Getter und Setter realisieren. Mir ist klar, dass das so ist, nur wieso sollte das besser sein, als Eigenschaften auch in Interfaces zuzulassen?

> Der Hauptanwendungszweck von Interfaces ist, den Nutzer einer Klasse von ihrer tatsächlichen Implementierung zu trennen. Er sieht nur das Interface, und wie es implementiert ist, hat ihn nicht zu interessieren. Das Interface stellt den Kontrakt dar, der bereitgestellt wird und den ich nutzen kann. Durch die Trennung zwischen Kontrakt und Ausführung des Kontrakts entsteht Austauschbarkeit und insbesondere die Möglichkeit zum Mocken und Unit-Testen. Statische Typchecks sind nur ein Aspekt des Ganzen. Sie sind **der** Aspekt von Interfaces. Den gesamten Rest, den du beschreibst, darft du Polymorphie zu Gute rechnen. In Java sind Interfaces eben eine Möglichkeit Polymorphie zu realisieren. > Sowas geht nur mit Interfaces (oder, ja, abstrakten Superklassen, die ich wie Interfaces nutze). Gibt es dafür einen triftigen Grund? Vertikale Komposition, also Vererbung, sorgt für eine stärkere Kopplung der beteiligten Klassen als horizontale Komposition (durch Interfaces, Traits, Mixins...). Bei sehr kohärenten Zusammenhängen, kann man das machen. Im allgemeinen Fall würde ich zunächst davor zurückweichen. Und wie soll das in Sprachen ohne multipler Vererbung funktionieren? > In Sprachen wie PHP oder JavaScript kann man Interfaces tatsächlich auf ein technisches Muster für vorhandene Klassenelemente reduzieren, weil die Bindung Aufruf->Implementierung zur Laufzeit erfolgt. Womit wir wieder bei der Polymorphie wären. Diesmal durch Duck-Typing. > D.h. eine Eigenschaft in einem TypeScript-Interface ist unproblematisch Ich bin froh, dass du das sagst, nachdem du zu erst mit so harschen Worten die TypeScript-Entwickler beleidigt hast. > PHP hat weder diese duale Darstellung von Data- und Accessor-Properties, noch den get/set Syntaxzucker. Wenn ich in ein PHP Interface eine Eigenschaft schreibe, bedeutet das zur Laufzeit den direkten Zugriff auf ein Field. Und DAS ist ein Problem, weil ich ein Field nicht mocken oder nach Bedarf durch einen Methode substituieren kann. In PHP gibt es die "magischen" __get- und __set-Methoden, damit kannst du Zugriff auf Eigenschaften regeln. Dein Argument mit dem Mock kann ich nicht nachvollziehen. Wieso solltest du Abhängigkeiten von Eigenschaften nicht auflösen können? Das Interface würde ja nur die Existenz und den Typen der Eigenschaft festlegen. Ich glaube, dass dieses Problem gar nicht existiert, aber selbst wenn, würde ich sagen, dass man in einem solchen Fall die Eigenschaft eben nicht per Interface erfordern sollte. Man verliert ja durch die Möglichkeit nichts. Man gewinnt nur Einfachheit, Konsistenz und Ausdrucksmöglichkeit hinzu. > Deswegen muss ich in PHP, genau wie in Java, ein interfacefähiges Property durch explizite Getter und Setter realisieren. Mir ist klar, dass das so ist, nur wieso sollte das besser sein, als Eigenschaften auch in Interfaces zuzulassen?