Frage zur Vererbung

[Bodo1981]

Ich habe eine Klasse Fahrzeug (Oberklasse) von dieser Klasse erben MuskelbetriebenesFahrzeug und MotorbertriebenesFahrzeug. Dann gibt es da noch eine Klasse Fahrrad die von Muskelbetriebenes Fahrzeug erbt. Alle Klassen besitzen eine fahren() Methode.

Nun hab ich mir eine Testklasse geschrieben, die das ganze testet. Dabei bin ich auf den folgenden Gedanken gekommen:

Ich erzeuge eine Instanz von Fahrrad. Die hat ja eine eigene Methode fahren. Ist es aber möglich mit dieser Instanz die fahren Methode von der Oberklasse Fahrzeug aufzurufen? Habs schon mit super() probiert geht aber leider nicht. Falls einer weis wie das geht, könnte er mir bitte den Aufruf schreiben.

Merci schonmal

 

[KSG9|sebastian]

public class Fahren
{

	/**
	 * @param args
	 */
	public static void main(String[] args)
	{
		Fahrzeug f = new Fahrrad();
		f.fahren(200);

	}

}
public class Fahrrad extends Fahrzeug
{
	public void fahren(int meter){
		super.fahren(meter);
		
		System.out.println("Fahrrad fährt " + meter + " Meter.");
	}
}
public abstract class Fahrzeug
{
	public void fahren(int meter){
		System.out.println("Fahrzeug fährt " + meter + " Meter.");
	}

}

Ausgabe:

Fahrzeug fährt 200 Meter.
Fahrrad fährt 200 Meter.

Wie du siehst, es funktioniert mit "super"

Gruß

 

[Bodo1981]

Ja so hab ich es dann auch gelöst, aber ich mein jetzt ist es möglich in der Main-Methode direkt die Methode fahren() von Fahrzeug aufzurufen oder geht das nur so?

 

[EOB]

ne, geht wirklich nur so. wenn dein fahrzeug ein fahhrad ist, wird auch diese methode aufgerufen.

grüße

 

[Bodo1981]

Merci für die schnelle Antwort. Jetzt hab ich aber noch ne Frage:

Und zwar hab ich eine Klasse FahrradMitHilfsmotor die soll von Fahrrad UND MotorbetriebenesFahrzeug erben. Ich weis das es keine Mehrfachvererbung mit extends in Java gibt. Wie setz ich das trotzdem am besten um? Interface oder abstrakte Klassen?

 

[KSG9|sebastian]

Abstrakte Klasse wird dir nicht viel helfen. Wobei das vom Vererbungsbaum her nicht sinnvoll ist.

MusekelbetriebensFahrzeug und MotorbetriebenesFahrzeug stehen im Vererbungsbaum nebeneinander. Fahrrad ist eine spezielisierung von Museklbetriebenesfahrzeug. Jetzt willst du ne Querverbindung herstellen. Halte das nicht für sinnvoll.

Könntest das z.B. über eine separate Oberklasse wie z.B. DualangetriebenesFahrzeug machen. (würghs, was für ein Name)

 

[Bodo1981]

Respekt für den geilen Namen ;-) Stimmt das wär auch noch ne Möglichkeit, aber angenommen ich bilde mir ein Interface ein. Wie würde das genau gehen?

 

[EOB]

eine frage, was machst du, wenn du noch 10 weitere fahrräder hast (fahrradmitgrosserklingel, fahrradmitdickenreifen,....)? willst du dann pro fahrrad eine anlegen?

eventuell könnte man hier das dekorator muster anwenden. *schlautu*
also du hast dein fahrrad und dekorierst es mit motor und so weiter.

grüße

 

[KSG9|sebastian]

http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/DecoratorPattern.htm

Man sollte es auch nicht übertreiben mit Vererbung. Evtl. würde schon ein Attribut "hilfsmotor" reichen...

 

[EOB]

da haste recht....over engineering ist auch nicht gut 🙂. aber wenns dann mehr wird, kommt es früher oder später zu unübersichtlichem code. solange wirklich nur der hilfsmotor da ist, könnte man das wohl mit nem booleschen wert steuern. sinds aber eben mehr, wirds unübersichtlich und dadurch auf fehleranfälliger.

grüße

 

[hupfdule]

da haste recht....over engineering ist auch nicht gut 🙂. aber wenns dann mehr wird, kommt es früher oder später zu unübersichtlichem code. solange wirklich nur der hilfsmotor da ist, könnte man das wohl mit nem booleschen wert steuern. sinds aber eben mehr, wirds unübersichtlich und dadurch auf fehleranfälliger.

Dann ist auch die richtige Zeit zum Refactoring. Over Engineering ist viel schlimmer. Ich habe es nun schon in mehreren Projekten erlebt, dass die ursprünglichen Entwickler sich eine ganz tolle Architektur mit allen möglichen Entwurfsmustern ausgedacht haben und am Ende konnte niemand mehr den Code durchblicken vor lauter Interfaces, abstrakten Klassen etc.

Der Code und die gesamte Architektur sollte immer so einfach wie möglich gehalten werden. So lange nicht absehbar ist, dass neue Klassen wirklich gerechtfertigt sind, sollte diese weggelassen werden. Außerdem zwingt das später zu einem anständigen Refactoring. Was auch ein Punkt ist, der in der Praxis viel zu sehr vernachlässigt wird. ;-)

 

[Tellerrand]

Respekt für den geilen Namen ;-) Stimmt das wär auch noch ne Möglichkeit, aber angenommen ich bilde mir ein Interface ein. Wie würde das genau gehen?

Mein Vorschlag dazu als Skizze:
Interface Muskelbetrieben
Interface Motorbetrieben

abstract Fahrzeug
MotorbetriebenesFahrzeug extends Fahrzeug implements Motorbetrieben
MuskelFahrzeug extends Fahrzeug implments Muskelbetrieben
DualbetribenesFahrzeug extends Fahrzeug implements Muskelbetrieben, Motorbetrieben


Over Engineering:
Klar wenn 5 Entwickler versuchen ein großes Projekt zu realisieren und dann jeder auch alles verstehen will entstehen Probleme.
Das OOP Konzept ist ja gerade so gestaltet, dass man nicht alles verstehen muss. Die Java Referenzen sind ein gutes Beispiel dafür, wer kennt sich schon mit allen mitgelieferten Paketen und Klassen aus. (Und wozu sollte man das?)
"Der Code und die gesamte Architektur sollte immer so einfach wie möglich gehalten werden."
Wenn der Entwickler es nicht einfacher macht, dann macht er in meinen Augen was falsch 😉
Da stimme ich zu, Klassen und Interfaces nur, wenn man sie braucht, bzw. sie es vereinfachen. Interfaces nachträglich zu extrahieren ist dank den netten Enwicklungsumgebungen auch kein problem.

Meiner Meinung nach ist es hier z.B. erstmal die Frage, ob das Programm zwei verschiedene Antriebe unterschiedlich bearbeiten muss.
Wenn ja ist mir eine unterschiedliche fahren() Implementierung lieber, als später im Code zig Stellen if(ding.isMotorbetrieben()) zu haben.
Sollten die Interfaces keine unterschiedlichen Methoden beherbergen, dann lässt man auch diese lieber. Markierungsinterfaces werden ab und an mal verwendet, aber sie sind nicht das erste Mittel der Wahl.

 

[EOB]

so entstünde aber viel doppelter code. jedes fahrzeug, was jetzt muskelbetrieben oder motorbetrieben ist, muss den code implementieren, auch wenn es genau gleich funktionieren würde. finde ich nicht so gut. eine lösung wäre ein interface in der art:

interface Driven{
    drive();
}

und dann jeweils

class MotorDriven implements Driven{
    drive(){
        //fahre mit motor
    }
}

class MuscleDriven implements Driven{
    drive(){
        //fahre mit muskelkraft
    }
}

dann eben jeweils die passende methode aufrufen...imho.

grüße

 

[nols]

muss es nicht, da muskelbetrieben und motorbetrieben abstrakte Klassen sind, kann diese die Funktion implementieren.
Und wenns nötig ist wird sie halt überschrieben.

Oder seh ich jetzt vor lauter Wald die Bäume nicht?

 

[Tellerrand]

Ja, das sind schon Klassen, ob sie abstrakt sein sollten sei mal dahingestellt.
Wobei es sinnig wäre die beiden Interfaces noch von einem gemeinsamen Interface erben zu lassen. (Fällt mir grad so ein 😉)

 

[EOB]

warum sollte das sinnig sein? oder was meintest du?

grüße