nicht angemeldet
Rolf b(...) Statische Typchecks sind nur ein Aspekt des Ganzen.
Sie sind der Aspekt von Interfaces.
Da wir hier beide unsere Meinungen in den Raum stellen - und ich für meine Meinung keine reputable Belegquelle aus der Tasche ziehen kann - will ich dazu einfach mal dies sagen: Einigen wir uns darauf, dass wir uneinig sind.
Den gesamten Rest, den du beschreibst, darfst du Polymorphie zu Gute rechnen. In Java sind Interfaces eben eine Möglichkeit Polymorphie zu realisieren.
Wenn man den Blick nur auf dynamische Sprachen richtet (Javascript, PHP), sind Interfaces nur eine Liste von Hinweisen an die Entwicklungsumgebung (oder den Compiler, soweit einer nötig ist). Es gibt aber dazu noch die "statischen" Sprachen, und da brauche ich Interfaces als Konstrukt, um den Zeitpunkt der Methodenbindung vom Zeitpunkt des Compilierens oder Ladens zum Moment der Objekterzeugung zu verschieben. Möglicherweise gibt es statische Sprachen, die das auch ohne Interfaces können, die kenne ich dann nicht.
Polymorphie ist eine Voraussetzung für Mocks in Unittests oder Proxies in Remote-Diensten. Ohne Interface gibt's in den mir bekannten statischen Sprachen keine Polymorphie, daher sehe ich dort Interfaces als Voraussetzung für Unittests und Remote-Proxies an.
Sowas geht nur mit Interfaces (oder, ja, abstrakten Superklassen, die ich wie Interfaces nutze). Gibt es dafür einen triftigen Grund?
Sorry. Das habe ich falsch formuliert. "Die man an Stelle von Interfaces auch verwenden kann" hätte ich sagen müssen, und natürlich brauchst Du eine Sprache wie C++, um Interfaces komplett durch abstrakte Superklassen zu ersetzen. Das heißt jetzt nicht, dass es gut ist, das zu tun. Aber wenn ich sage "Das geht nur mit Interfaces", dann ist das als Absolutum falsch und irgendein Korinthenkacker hätte dann die abstrakten Superklassen als Einwand bringen können.
(In) PHP (kann ich) ein Field nicht mocken oder nach Bedarf durch einen Methode substituieren (...).
In PHP gibt es die "magischen" __get- und __set-Methoden, damit kannst du Zugriff auf Eigenschaften regeln.
Ja sicher. Aber das nennst Du doch wohl nicht Implementierung. Das ist eine armseliger, laufzeitverschwendender Notlösung. Für Unit-Tests wäre das wohl akzeptabel. Für Proxies z.B. nicht.
Dein Argument mit dem Mock kann ich nicht nachvollziehen. Wieso solltest du Abhängigkeiten von Eigenschaften nicht auflösen können?
Weil das eine Syntax-Eigenschaft vieler Programmierersprachen, auch PHP, ist. Aus $a->Dings generiert er einen Zugriff auf ein Field, und keinen Methodenaufruf getDings(). Und den kannst du nur mit magischen Methoden umleiten. Auf die Eigenschaft in diesem Fall "am Interface vorbei" zuzugreifen beseitigt die Idee der Trennung von Deklaration und Implementation und ist daher beim Arbeiten mit Interfaces abzulehnen. Bei einem Remoting-Proxy KANNST Du nicht am Interface vorbei. Deswegen müssen Properties durch Methodenaufrufe dargestellt werden. Weil Field-Zugriffe im allgemeinen direkt auf den Objektspeicher gehen und daher nicht umgeleitet werden können. __get() ist da für mich keine Lösung, sondern eine Schwachsinnsidee von Rasmus L.
Rolf
TS
mermshaus