Wann Vererbung und wann Interface verwenden?

[kossy]

Hallo zusammen !

Häufig steht man vor der Frage, wann man eine Vererbungshierarchie aufbauen soll und wann es besser ist, ausschließlich mit Interfaces zu arbeiten.

Der Grundtenor lautet ja: Lieber mit Interfaces arbeiten, als mit Vererbungen.

Aber dennoch stellt sich mir die Frage, wann ich was verwenden soll. Gibt es dafür so eine Art Pauschalantwort? Danke für die Hilfe !

Grüße
Kossy

 

[Crian]

Eine Pauschalantwort gibt es nicht. Aber wenn man sich aus (guten Gründen) für eine Vererbung entschieden hat, dann sollte einem klar sein, dass man die Klassen nicht auch noch von anderen Quellen erben lassen kann. Wenn man also nicht wirklich Basisfunktionalität braucht, sondern nur die Schnittstelle, dann sollte man Interface verwenden.

Ggf. lässt sich auch beides verwenden, um gegen das Interface zu programmieren, aber dennoch Basisfunktionalität in einer Klassenhierarchie zu haben, die sowohl von der Basisklasse erbt als auch das Interface implementiert.

 

[pl4gu33]

Naja, Vererbung is denke ich sinnvoll, wenn man ein Oberbegriff hat z.b. Person und dann Unterpersonen wie Arbeitnehmer, Arbeitgeber.

Interface sind denke ich sinnvoll, wenn man zum Beispiel zwischen Schichten eine "Kommunikation" herstellen will und somit gewährleistet, dass bestimmte Methoden auf jeden Fall vorhanden und implementiert sind.

lasse mich da auch gern verbessern

 

[asdasdasddas]

Hallo ein Beispiel wäre vielleicht sowas für Vererbung:

public class Auto {

	public void fahren(){
		System.out.println("Brumm");
	}
}
public class Audi extends Auto{}
public class VW extends Auto{}

So, bei der Vererbung gibt das Auto das Verhalten "fahren" vor.
Wenn also ein Subobject ein Verhalten vom SuperObject haben soll, dann nimmt man die Vererbung.

Beispiel bei Interfaces:

public interface Person {
	void pipiMachen();
}
public class MaenchlichePerson implements Person{
	@Override
	public void pipiMachen() {
		System.out.println("stehend");
	}
}

public class WeiblichePerson implements Person{
	@Override
	public void pipiMachen() {
		System.out.println("sitzend");
	}
}

So das Interface Person gibt vor was die Klasse(Object vo Typ Person) implementieren müssen, aber nicht wie sie es machen. Also muss jede Klasse für das Verhalten selber sorgen.
Vielleicht wird es dadurch klarer.

Mfg

 

[vanny]

der Aspekt der Kommunikation verschiedener Klassen trifft es eigentlich recht gut.

Unterperson klingt so diskriminierend^^.
Ich habe aktuell ein Projekt, bei dem ich die Personen als Interface nutze.
In meinem Fall geht es um die reinen PersonenDaten, welche gleichrangig für Einlieferer und Kunden behandelt werden.

Es würde sich auch anbieten, das Interface zu nutzen, wenn es Arbeitgeber und Arbeitnehmer wären, solange es nur um die PersonenDaten ginge.

Wenn mans verallgemeinern möchte, dann "Vererbung/Delegation bei Hierachie" und "Interface bei gleichrangiger Behandlung".
Gibts natürlich noch viel mehr Anwendungsmöglichkeiten ist aber vielleicht schon mal ne Entscheidungshilfe für dich.

Gruß Vanny

 

[Tomate_Salat]

Ich programmiere sehr gerne gegen Interfaces. Die eigentl. Anwendung bezieht sich dann fast ausschließlich darauf und ich kann einfach Implementierungen austauschen (vor allem, da ich Guice einsetze).

Von Klassen erben zu lassen, macht eben dann Sinn, wenn man bestehenden Implementierungen weiter verwenden will (Redundants vermeiden).

Wo ich keine Interfaces einsetze sind bei (ich nenns mal) Property Holder. Also z.B.:

public class DBFiel {
private String name;
private boolean isNullAble;
//... usw

public DBField(String name, boolean isNullAble, ...)

public String getName() //...
}

aber pauschalisieren würde ich da jetzt nichts. Das kann sich von Anwendungsfall zu Anwendungsfall zu Programmierers vorlieben immer wieder unterscheiden.

 

[tfa]

Von Klassen erben zu lassen, macht eben dann Sinn, wenn man bestehenden Implementierungen weiter verwenden will

Das ist meiner Meinung nach einer der größten Fehler, die man beim Einsatz von Vererbung machen kann. Vererbung dient nicht zur Code-Wiederverwertung (das kann man über Delegation lösen). Sie muss sich immer an den Prinzipien des objektorientierten Designs halten (is-a-Beziehung).

 

[Tomate_Salat]

Naja, hab das ein wenig anderster gemeint. Angenommen man hat eine Klasse Säugetier mit der Methode atmen. Darin wird beschrieben, dass die Lunge dazu verwendet wird. Das (Säugetier) jetzt als Interface zu behandeln wäre imho nicht sinnvoll, da alle Säugetiere afaik das auf die gleiche Art und Weiße machen -> Ergo das kommt in die Klasse Säugetier und gilt so erstmal für alle, die auch eines sind (z.b. Hund).

Von der "is-a-Beziehung" bin ich einfach mal ausgegangen, dass es logisch auch so ist.

 

[JohannisderKaeufer]

Vögel sind keine Säugetiere.

Sie atmen auch mit der Lunge.

Gerade mit Vererbung kriegst du hier Redundanz rein.

Da du bei Vögeln nicht die implementierung von Säugetieren verwenden kannst.

Deshalb Interface für eben diese Beschreibung, Die Beschreibung in eine Eigene Klasse und Delegation.

 

[Marco13]

JohannisderKaeufer: 1
Tomate_Salat: 0
( :bae: )

Schönes Gegenbeispiel. Das passt wohl zu dem, was als Beispiel in "Entwurfsmuster von Kopf bis Fuß" aufgeführt ist, schnelle Google-Buch-Suche dazu...

 

[ARadauer]

Dieses Audi VW Beispiel ist ein typisches Beispiel wie man es meiner Meinung nach nicht machen soll....
Das sind unterschiedliche Ausprägungen der Eigenschaften, wenn sie unterschiedliches Verhalten haben, dann würd ich dieses Verhalten kapseln und über Komposition austauschbar machen....

 

[Jango]

JohannisderKaeufer: 1
Tomate_Salat: 0

:toll:
Wobei ich mich gerade frage, was 'anderster' bedeutet:

Naja, hab das ein wenig anderster gemeint

 

[Tomate_Salat]

JohannisderKaeufer: 1
Tomate_Salat: 0
( :bae: )

in meinen Programmen gibt es keine Vögel oder Reptilien o.ä. Da passt dass schon so!:bae:

Wobei ich mich gerade frage, was 'anderster' bedeutet

das Hochdeutsche Wort für anerschder