Java Eine einfache OO Frage

Hallo, mal eine 'einfache' Frage an Euch wie man das folgende Problem am besten im Stil der OO lösen würde (habe zwar Java ausgewählt, aber im Grunde ist die Sprache hier egal).

Nehmen wir an ich habe eine Oberklasse Fahrzeuge darunter dann paar Unterklassen, sagen wir mal PKW, LKW, Motorrad ...

Die Unterklassen erben natürlich von der Oberklasse wie sich das gehört und ist alles schön wie es nunmal sein sollte. Jetzt die Frage: Fahrzeuge können alle 'starten', sagen wir starten() ist eine Funktion (starten wie Motor anschmeissen ). Wo und wie wird am besten diese Funktion deklariert? Deklariere ich das einfach in die Oberklasse und die Unterklassen überschreiben das am besten? Oder erstelle ich einen Interface mit starten() drinne und die Unterklassen enthalten alle den gleichen Interface? Oder nur die Oberklasse nimmt den Interface? Wie ist das am besten zu machen? Stichwort OO und Polymorphie...

Danke und Gruß

Also wenn wirklich alle Kinder von Fahrzeug starten können und Fahrzeug Abstrakt ist, würde ich den Rumpf dort deklarieren.

Bei sowas wie "Kickstart" Was nicht alle Fahrzeuge Können würde ich ein Interface machen und nur die Klassen das implementieren lassen, die das können.

Im Prinzip ist das aber egal und da gibts bestimmt 1000 Wege das zu lösen.

Es hängt davon ab wie es angesehen werden soll. Falls z.B. man sagt PKW und LKW starten doch nicht gleich (mechanisch), dann wäre ein Interface in Fahrzeuge und die jeweilige Implementierung die beste Lösung. Falls es aber egal ist, wäre ein Interface und die Implementierung in der Klasse Fahrzeug die beste Lösung finde ich.

Okey, also ist die besten Lösung immer einen Interface zu machen nur muss man dann entscheiden ob das nur die Oberklasse oder doch nur einige Unterklassen kriegen sollten?

p0pp schrieb:

Also wenn wirklich alle Kinder von Fahrzeug starten können und Fahrzeug Abstrakt ist, würde ich den Rumpf dort deklarieren.

Bei sowas wie "Kickstart" Was nicht alle Fahrzeuge Können würde ich ein Interface machen und nur die Klassen das implementieren lassen, die das können.

Im Prinzip ist das aber egal und da gibts bestimmt 1000 Wege das zu lösen.

Zum Vergrößern anklicken....

Und naja was heißt beste Lösung, nehmen wir an man weiß nicht wie komplex das ganze Pojekt später wird und man möchte aber sicher sein das man nicht vieles umschreiben muss. Also man weiß nicht ob es noch ein 'Kickstart' kommen könnte oder nicht. Wie geht man dann am besten vor?

Wenn du weißt, dass alle Fahrzeuge die Start()-Methode brauchen, dann würde ich sie in der abstrakten Oberklasse hinterlegen, sodass jede Unterklasse sie auch wirklich benutzt.
Zusatzfunktionen können dann via Interface hinzugefügt werden.

Es hängt aber davon ab, ob man z.b. Fahrräder auch als Fahrzeuge in weitesten Sinne sieht etc.

Dann könnte man das halt noch weiter unterteilen... und aufspalten, sodass es möglicherweise keinen Sinn mehr macht, die start()-Methode in Fahrzeuge zumachen (den wie schon gesagt, startet ein Rad wohl nicht).

Viele verschiedene Meinungen Ich habe bisher auch so gearbeitet das meine Abstrakte Oberklasse die Methoden enthalten hat die die Unterklassen geerbt haben. Hat alles prima geklappt. Ich habe halt sehr selten mit Interfaces gearbeitet. Guckt man aber ein paar gute Opensource Projekte an (sie das Java, C#, ...), sieht man massig Interfaces, fast soviele wie es eigentlich Klassen es gibt Und wenn die Profis das so machen, frage ich mich waum ich sowas nie brauche bzw. benutze - ist anscheinend richtig viele Interfaces zu benutzen.

Warum die viele Interfaces benutzen ist ganz einfach.

Viele Entwickler -> Viele Subsysteme -> Fest Definierte Schnittstellen werden benötigt -> Interfaces sind das Mittel der Wahl.

Ich würde es ohne Interface lösen und die Methode einfach in der abstrakten Klasse deklarieren. Ich bin sowieso recht skeptisch, was Interfaces betrifft. In 7 Jahren programmieren habe ich vor 2 Wochen das erste Mal tatsächlich eins gebraucht. Es ging in dem Fall darum, dass ich verschiedene Elemente wie Textboxen, Images etc. zusammen speichern musste. Außerdem sollten die Objekte anhand eines Keys vergleichbar sein. Dort war dann ein Interface die einzig sinnvolle Lösung.

Aber in einer Situation, wie p0pp sie beschreibt, war ich bisher auch nie. Zwei Entwickler basteln hier normalerweise gleichzeitig an einem Projekt.

Naja, auf Teufel-komm-raus Interfaces zu benutzen ist auch nicht wirklich sinnvoll.

Liegt, wie p0pp schon sagte, dass man bei großen Projekten viel planen muss und deshalb nicht alle 5min Schnittstellen ändern kann, weil man sonst das ganze Projekt eventuell kaputt macht, deshalb wird vor der Umsetzung über Schnittstellen diskutiert und diese festgelegt (in interfaces).


Bei kleineren Projekten(2-5Mann) oder bei privater Hobbyprogrammierung sieht man Interfaces hingegen recht selten, außer man hat auch Leute dabei, die vorher alles durchplanen wollen.

Ah okey, verstehe. Also wenn man alleine unterwegs ist und das Projekt nicht übergroß ist: Interfaces nicht immer von nöten. Wenn man aber schon vornweg weiß das das Projekt sehr groß wird und auch andere daran rumfuchteln: Interfaces wo es nur geht.

Interfaces setzt du ein, wenn du Klassen eine Funktion aufs Auge drücken möchtest, die sie definitiv implementieren müssen.

(Vgl. Observer-Pattern als Beispiel).

Ich melde mich bei einer Waage an, weil mich die Waage benachrichtigen soll wenn sich etwas tut.
Ich muss meinem beobachtenden Objekt also das Interface des Listeners implementieren. Dieses Interface ist die Schnittstelle die vom konkreten Subjekt (der Waage in diesem Fall) aufgerufen wird für alle, die sich bei ihr angemeldet haben zum zuhören.

Sehr minimal, aber vlt. hilft es dir in der Vorstellung?

Ist übrigens immer eine tolle Frage, die selten passend beantwortet wurde, dass sie jeder versteht.
http://www.javaworld.com/javaworld/javaqa/2001-04/03-qa-0420-abstract.html

Ist ein Versuch, den ich akzeptabel finde.