Schon wieder: Warum Interfaces

[einbeliebigername]

Hallo,

Zitat von DeddyH:

Zitat von einbeliebigername:

Und das Verhältnis von 1. und 3. sollte deutlich zu 1. tendieren.

Das würde ich so pauschal nicht stehen lassen, es kommt immer auf den Einzelfall an. Will ich z.B. eine Art Framework schreiben, dann sollte ich mir sehr genau überlegen, ob ich nicht lieber von Anfang an auf Interfaces setze, da wahrscheinlich die unterschiedlichsten Typen auf mich zukommen. Da wird es dann sehr schwer bis schlicht unmöglich, eine saubere Klassenstruktur hinzubekommen. Das Schöne an der Verwendung von Interfaces ist es ja gerade, dass mich der dahinterliegende Typ nicht im Geringsten interessiert und ich mich somit auf die Methoden und Eigenschaften konzentrieren kann, die im Interface zugesichert wurden.

Aber wie schaffst du es, ohne über Klassenstrukturen nachzudenken, bei der Implementierung eines Interfaces in mehreren Klassen Codeduplikate zu vermeiden. Um bei dem iAdresse-Beispiel zu bleiben. Wenn man TAdresse1= class(iAdresse) , TAdresse2= class(iAdresse) und TAdresse3= class(iAdresse) hat, dann haben doch die drei Klassen jeweils ein function GetFirstName: string; . Der Funktionsrumpf sieht doch bei allen gleich aus ( begin result:= fFirstName; end; ). Also kommt man doch zum Schluss GetFirstName in eine Basisklasse zu verschieben. Bestimmt sind 90-100% der Implementierung von iAdresse gleich. Dann kann man doch auch das Interface in der Basisklasse implementieren. Und damit wäre die Basisklasse die einzige, welche das Interface implementiert. Und somit wäre das Interface überflüssig. Sei denn du willst, das jemand auch TFormAdresse= class(TForm, iAdresse) machen kann, was ich softwaredesigntechnisch für eine absolute Katastrophe halte.

Schon allein der Umstand, dass ein Property im Interface einen Getter in der implementierenden Klasse benötigt, reicht für mich aus, Interfaces ausschließlich nur da einzusetzen, wo es mit Vererbung und abstrakten Klassen keine Lösung gibt.

einbeliebigername.