Interfaces -- Do and Don'ts

[s.h.a.r.k]

Hallo zusammen,

bin gerade immer wieder am überlegen wie ich gewisse Interfaces entwickle. ich meine hier keine User Interfaces, sondern die zum programmieren :) dann überlege ich mir immer, wie ich gewissen Code dann verwenden will, also in dem Fall eben die Schnittstellen und entwerfe diese dann entsprechend. meist mag das okay sein, aber ich denke, dass es bei Sowas schon ein paar "Regeln" gibt? Mit Regeln meine ich Sowas wie "halte deine Interfaces schlank". was fällt euch dies bzgl noch so ein?

[r2c2]

Ja, da gibts ein paar:

Am bekanntesten ist wohl das InterfaceSegregationPrinciple. In meiner Liste von Prinzipien hab ich außerdem noch "Few Interfaces", "Small Interfaces" und "Explicit Interfaces gefunden. Die drei stammen wohl von Bertrand Meyer. Einen Link hab ich mir dazu nicht notiert. Aber mit den Stichworten solltest du was finden.

Das sind jetzt die, die sich explizit auf Interfaces beziehen. Daneben gelten aber noch zig andere, die aber genauso für Klassen gelten. Soll ich da auch noch welche von Posten? Meine Liste ist lang (ich finde solche Prinzipien oder "Daumenregeln" außerordentlich interessant. Ein bisschen was dazu findest du hier: http://www.christian-rehn.de/tag/daumenregeln/

mfg

Christian

[sx2008]

Vielleicht nicht das was du hören möchtest...

Wenn ein Interface nur von einer einzigen Klasse implementiert wird und auch kein Interface für Automatisierung ist, dann sollte man kein Interface verwenden.
Grund:
Soll das Interface geändert werden, dann muss an mindestens zwei Stellen geändert werden - in der Deklaration des Interface und in der implementierenden Klasse.
Da dies doppelte Arbeit bedeutet wird der Programmierer manchmal auf eine Änderung verzichten, obwohl die Änderung eine Verbesserung wäre.

Fazit:
Interfaces müssen sorgfältig geplant werden!
Eine spätere Änderung kann je nach Anzahl der implementierenden Klassen recht aufwändig werden.

[jaenicke]

Zitat:

Zitat von sx2008 (Beitrag 1173743)

Wenn ein Interface nur von einer einzigen Klasse implementiert wird und auch kein Interface für Automatisierung ist, dann sollte man kein Interface verwenden.

Da fehlt noch mindestens die Einbindung von DLLs. Denn um Objekte dorthin zu liefern, braucht man Interfaces (abgesehen von Packages, aber...).

Und dann gibt es noch das Prinzip die Implementierungen abzukoppeln:
http://www.nickhodges.com/page/Why-Y...eferences.aspx
Da es da in Delphi ein paar deutliche Einschränkungen gibt, kann ich mich damit als generelles Prinzip nicht wirklich anfreunden, aber es ist eigentlich sehr interessant.

[Furtbichler]

Interfaces beschreiben das Verhalten sowie die Interaktion der einzelnen Subsysteme bzw. Teilen davon. Klassen implementieren dieses Verhalten.

Das ist ein gravierender Unterschied, und ich würde bei komplexen Systemen immer erst die Schnittstellen definieren und später dann das Verhalten.

Alleine schon Konstrukte wie:

Delphi-Quellcode:

Type
  TCombinedClass = Class (TSomeBaseClass, IListener, IRemover, IPad, IPod)

zeigen, wie klarer ich Systeme entwerfen kann. Denn ich beschreibe das Verhalten der einzelnen Interfaces (IListener, IRemover....) separat und kann dieses Verhalten dann meinen Klassen zuweisen.

Das geht alleine mit Klassen nicht.

[s.h.a.r.k]

Na, das ist doch schon mal ein Anfang :thumb: Danke schon mal für die ganzen Ideen! So hatte ich mir das gedacht.

Am Schluss gießen wir dann noch ein Buch mit 1000 Seiten Umfang draus :mrgreen: