Interface als Instanzvariable = gutes Design

[kossy]

Hallo nochmal !

Ich stehe in meinem System davor eine konkrete Klasse mittlerweile an mehreren Stellen zu verwenden. Bisher habe ich sie in anderen Klasse immer über eine Referenzvariable von exakt demselben Typ der Klasse selbst angesprochen.

Bisher sind die Methoden in der Klasse immer dieselben, so dass ich nun überlege, an Aufrufstellen nicht mehr eine Referenzvarable vom Typ dieser Klasse zu verwenden, sondern ein Interface, welches diese Klasse implementiert.

So weit so gut, aber u.U. könnten auch noch weitere Methoden in der Klasse dazukommen. Wäre das vielleicht eine abstrakte Oberklasse sinnvoller, auch wenn die Vererbung das Risiko von unerwünschten Nebeneffelten beinhaltet? Oder ist ein Interface als Referenzvariable der bessere Weg auch unter Berücksichtigung, dass weitere Anforderungen programmatisch umgesetzt werden müssen?

Grüße
Kossy

 

[Vancold]

Hey


Handelt es sich um ein Objekt das du Referenzierst oder eine Klasse die unabhängig von einem Objekt besteht. (Math.) Wenn das der Fall ist mach alles statisch (also die Methoden)

LG

Rene

 

[Marco13]

Oder ist ein Interface als Referenzvariable der bessere Weg

... üblicherweise ja ...

auch unter Berücksichtigung, dass weitere Anforderungen programmatisch umgesetzt werden müssen?

... wo ist dann so gesehen der Unterschied, ob die Klasse oder das Interface erweitert werden?

WICHTIG: Das war eine halb-rethorische Frage: Wenn das Interface von anderen Implementiert werden soll, macht das einen wichtigen Unterschied: Wenn man zum Interface eine Methode hinzufügt, funktionieren die bisherigen Implementierungen nicht mehr (Extension Methods kommen erst ab Java 8). Es kommt etwas auf den Zusammenhang an...

 

[kossy]

Hallo !

Wäre es evtl. eine Option, ein Interface zu deklarieren, dass dann von einer abstrakten Klasse implementiert wird und meine konrekte Klasse dann von dieser abstrakten Klasse abgeleitet wird (ähnliches Prinzip wie in Java Swing mit den Adapterklassen)?

Also in der abstrakten Klasse stehen dann nur konkrete Methoden drin (also die, die im Interface defineirt sind), aber meine konkrete Klasse unterhalb der abstrakten Klasse muss sich dann nicht um alle Implemntierungen des Interfaces kümmern, das würde dann die abstrakten Klasse erledigen.

In den weiteren Codezeilen innerhalb anderen Klasse würde ich dann trotzdem mit Referenzvariablem vom Typ des Interfaces arbeiten und hier gegen meine konkrete Klasse (und nicht die abstrakte Klasse) referenzieren.

Wäre das eine mögliche und langhaltig gute Option?

Grüße
Kossy

 

[timbeau]

Ich habe es in einem Projekt von mir so gemacht wie du vorschlägst. Letztendlich sind viele endgültige Klassen sehr groß geworden. Man soll ja eher Komposition denn Vererbung nutzen.

Wie es bei dir aussieht kann ich natürlich nicht genau sagen aber das Monster-Interface mit 200 Methoden ist halt auch nicht so toll.

 

[bygones]

Hallo !

Wäre es evtl. eine Option, ein Interface zu deklarieren, dass dann von einer abstrakten Klasse implementiert wird und meine konrekte Klasse dann von dieser abstrakten Klasse abgeleitet wird (ähnliches Prinzip wie in Java Swing mit den Adapterklassen)?

Also in der abstrakten Klasse stehen dann nur konkrete Methoden drin (also die, die im Interface defineirt sind), aber meine konkrete Klasse unterhalb der abstrakten Klasse muss sich dann nicht um alle Implemntierungen des Interfaces kümmern, das würde dann die abstrakten Klasse erledigen.

In den weiteren Codezeilen innerhalb anderen Klasse würde ich dann trotzdem mit Referenzvariablem vom Typ des Interfaces arbeiten und hier gegen meine konkrete Klasse (und nicht die abstrakte Klasse) referenzieren.

Wäre das eine mögliche und langhaltig gute Option?

Grüße
Kossy

ich versteh nicht so ganz dein ausgangspunkt, aber nur eine abstrakte Klasse einzufuehren, damit eine Implementierung nicht so viel schreiben muss ist unsinn. Eine abstrakte Klasse sollte genommen werden wenn es mehrere Implementierungen des selben Interfaces gibt, welche Gemeinsamkeiten haben und man somit Redundanz verringern will. Und warum ist diese dann ueberhaupt abstrakt wenn sie alle implementierungen des Interfaces schon macht ?!

 

[Marco13]

Ja, so ganz ist nicht klar, worauf sich die Frage bezieht. Üblicherweise geht es ja nicht darum, was man wo übergibt, sondern als was das dort bekannt ist. Zumindest sollte man IMHO tunlichst vermeiden, irgendeine Abstrakte Klasse "bekannt" zu machen, oder anzunehmen, dass man eine solche bekommt (auch wenn man sie natürlich heimlich still und leise verwenden kann).

Als Beispiel: Das ist OK

class TypeA
{
    private SomeInterface x;
 
    public void setX(SomeInterface x) { this.x = x; }
    public void doSomething() { x.doit(); }
}

Das folgende ist IMHO fragwürdig, weil dann der Sinn des Interfaces etwas verloren geht, und die Abstrakte Klasse überall bekannt ist:

class TypeB
{
    private SomeAbstractClassImplementingAnInterface x;
 
    public void setX(SomeAbstractClassImplementingAnInterface  x) { this.x = x; }
    public void doSomething() { x.doit(); }
}

(Es hätte den theoretischen Vorteil, dass man weitere Methoden zur abstract class hinzufügen kann, und niemand anderes sich um deren Implementierung kümmern muss, aber das ist SEHR oberflächlich betrachtet und sollte genauer durchgedacht werden)

Und schließlich noch

class TypeC
{
    private ConcreteClass x;
 
    public void setX(ConcreteClass x) { this.x = x; }
    public void doSomething() { x.doit(); }
}

Was natürlich nicht unüblich ist, aber in bezug auf Erweiterbarkeit und Abstraktion ist's damit u.U. nicht so weit her...