Wenn man Interfaces einsetzt muss man gleichzeitig auch einen Preis dafür bezahlen.
Man muss die Methoden nicht nur im Interface deklarieren, sondern auch in den Klassen nochmals mit genau gleicher Signatur deklarieren.
Das mag auf den 1. Blick noch kein Problem darstellen; man muss ja nur die Methoden aus dem Interface kopieren und in die betroffenen Klassen einfügen (per Copy & Paste).
Es baut sich aber ein gewissen psychologischer Widerstand gegen das Ändern von Interfaces auf.
"Eigentlich müsste ich ja noch eine weitere Funktion in das Interface XY einbauen, aber dann muss ich das in 5 weiteren Klassen nachziehen. Da hab' ich gerade keine Zeit dafür, drum lass ich es lieber mal so wie es ist"
Daraus kann man den Schluss ziehen, dass wenn man Interfaces verwendet, sollte man dies sehr sorgfältig tun.
Wenn man z.B. Methoden in ein Interface aufnimmt, die später eigentlich gar nicht gebraucht werden, dann ist das auch verschwendete Arbeit und ein Störfaktor im Sourcecode.
Als Delphi-Programmierer muss man aber noch einen weiteren Preis bezahlen; das leidige Thema mit der Referenzzählung von Interfaces.
Sobald man ein Objekt über ein Interface anspricht, hat man die Verantwortung für die Lebensdauer praktisch an die Referenzzählung abgetreten.
Danach darf oder sollte man das Objekt nicht mehr über die normale Objektvariable ansprechen.
Es gibt da Dinge die das Programmieren im gemischten Umfeld von Interface-Zeigern und Objekt-Zeigern nicht gerade einfach machen.
Ein .NET-Programmierer hat es da viel einfacher (*), da Objekt- und Interface-Referenzen unter .NET einer gemeinsamen Garbagecollection unterliegen.
Fazit:
Interfaces sind eine gute Sache, wenn man sich der Vor- und Nachteile genau bewusst ist.
Ein Projekt "auf Interfaces unzustellen" macht keinen Sinn;
wenn man aber gezielt neue Interfaces einführt (z.B. für Plugins) und weiss was man tut
ist man auf dem richtigen Weg.
*) neidisch kuck