Unterklassen mit unterschiedlicher Zustandsanzahl

[Moch]

Hallo,
Ich habe folgendes Problem:

Wir sollen derzeit als Klausurvorbereitung ein Programm schreiben, dass Ampeln simuliert.

Hierbei unterscheiden wir zwei Klassen von Ampeln
- 1. Die Klasse FussgaengerAmpel
- 2. Die Klasse FahrzeugAmpel
Beide erben von der abstrakten Klasse Ampel.
Die Klasse Ampel beinhaltet die Methode schalteWeiter(): void

schalteWeiter soll durch die Zustände einer Ampel schalten können.
Eine Fußgänger-Ampel kennt die Zustände Rot und Grün
Eine Fahrzeug-Ampel kennt die Zustände Rot, RotGelb, Gelb und Grün.

(jeder Zustand soll wieder eine einzelne Klasse sein, die von der abstrakten Klasse Zustand erbt)

Nun bin ich gerade bei einer Aufgabe angekommen, in welcher ich (ohne vorher mehr als die Oberklasse selbst erstellt zu haben) schalteWeiter() implementieren soll.

Hierbei stehe ich aber völlig auf dem Schlauch.
Wie kann ich hier zwischen den Ampeltypen (den Unterklassen) unterscheiden? (Die Fußgänger-Ampel soll ja nicht auf gelb bzw. rotgelb schalten können)

Sorry, aber hier ist eine sehr große Lücke in meinem Basiswissen vorhanden.

lieben Gruß
Moch

 

[Volvagia]

schalteWeiter() ist abstrakt? Dann schreibst du eben 2 verschiedene Dinge in die Subklassen. Was genau drinnen steht, ist ja egal, solange die Methode da ist kann sie aufgerufen werden.

 

[njans]

Mit Beispielsweise dem Vergleich instanceof kannst du abfragen ob ein Objekt eine Instanz einer Klasse ist
Du kannst auch in die abstrakte Klasse eine Methode einbauen, die dann zurück gibt, welcher Typ es ist. Das würdest du dann, je nach Ampel, einen anderen Wert zurückgeben lassen.

 

[Moch]

Hallo,
Danke erstmal für Deine Antwort, jedoch bin ich mir nicht sicher, ob ich das wirklich verstanden habe.

Ich habe das jetzt so verstanden, dass ich in beiden Unterklassen die Methode mit unterschiedlichem Inhalt implementiere.

Also so, wie unten beschrieben, oder habe ich das falsch verstanden?

lieben Gruß
Moch

public abstract class Ampel {
    public void schalteWeiter(){}
}

public class FUAmpel extends Ampel{
   public void schalteWeiter(){
   Anweisung 1;
}
}

public class FZAmpel extends Ampel{
   public void schalteWeiter(){
   Anweisung 2;
}
}

 

[njans]

Ja, sowas meinte er.

 

[Plastagen]

Und wenn du denn im Sourcecode nachher die Ampel folgendermaßen erzeugst:

Ampel fussgaengerAmpel = new FUAmpel();

und du rufst dann die Methode:

fussgaengerAmpel .schalteWeiter();

aufrufst, dann ruft er automatisch deine Implementation aus der Klasse FUAmpel() auf.

 

[Volvagia]

Genau. z. B. abstrakte Klasse Tier. Die 4 Tiere Pinguin, Affe, Leopard und Fisch bewegen sich vollkommen unterschiedlich. Pinguine watscheln, Affen bewegen sich eher Menschenähnlich, Leoparden springen mit den Hinterbeinen nach vor und stoßen sich ab (glaub ich zumindest), Fische bewegen ihre Hinterflossen hin und her. Tier bräuchte nur eine Methode bewegen(...), die entweder leer oder abstrakt implementiert wird. Wenn sie leer implementiert wird, wird bei unvollständigen Tieren gar nichts gemacht. Da sich aber soweit ich weiß alle bekannten Tiere irgendwie bewegen können, ist es sinnvoller sie abstrakt zu machen, und die Tierklassen dadurch zur implementation zu zwingen. Danach ist es egal, ob das Tier in der Methode watschelt, springt, sich im Kreis dreht oder explotiert (vom entwicklungsmäßigen und nicht biologischen Standpunkt her), du musst von einen Tier nur bewegen(...) aufrufen, eventuell Richtung etc. übergeben (je nach Signatur), und das Tier wird das tun, was in der Klasse steht, ganz egal um welches Tier es sich nun handelt.

 

[Moch]

Vielen Dank für die vielen Antwort.
Besonders auch für das sehr anschauliche Beispiel mit den Tieren

Jetzt noch eine Frage zu den beschriebenen Zuständen der Ampeln, wenn das okay ist

Ich habe ja wie beschrieben die beiden verschiedenen Ampeln und die Zustände.
Jeder Zustand (Rot, RotGelb, Gelb und Grün) ist jedoch - anders als ich es gemacht hätte - als eigene Unterklasse der Klasse Zustand vorgesehen -.-

Wie kann ich diese Zustände am sinnvollsten nutzen?

Ich hatte mir zunächst überlegt, in jede Klasse Zustand zuerst einen Bool-Wert einzufügen, der angibt, ob der Zustand aktiv ist oder nicht.
Das jedoch hat den offensichtlichen Nachteil, dass es nur für eine einzige Ampel funktioniert. Nutze ich zwei Ampeln, würde sich Veränderungen da gegenseitig überlagern. Hier stehe ich schon wieder auf dem Schlauch.

Ich habe jetzt die folgenden Klassen:
- Ampel (Unterklassen: FUAmpel, FZAmpel)
- Zustand (Unterklassen: Rot, RotGelb, Gelb, Grün)

Beide Klassen sind in unterschiedlichen Packages des gleichen Projekts.
Habt ihr da vielleicht noch einen kleinen Gedankenanstoß für mich? *lieb guckt*

lieben Gruß
Moch

 

[Volvagia]

Warum instanzierst du die Zustände nicht einfach statisch public o. protected in Ampel? Die Subampeln könnten sich die Zustände hohlen und auf sich setzen. Ich denke, es wird dann in der Ampel eine Methode wie get(gib)Zustand und setZustand geben. Set wird warscheinlich von außen nicht aufrufbar sein, weil das ganze über wechsle gemacht wird. Deshalb hohlst du dir einfach den momentanen Zustand der Superclass mit get im wechsle, und setzt mit set den nächsten. Du könntest z. B. in den Ampeln im Konstruktor Listen deklarieren, und alle Zustände der Reihe nach eintragen. Eine byte/int-Variable wie momentanerZustand etc. gibt die momentane Position der Liste an. Wenn du wechsle aufrufst, wird die Variable um 1 erhöht, oder auf 0 am Ende der Liste gesetzt (alternativ Modulo, aber ich finde es so hübscher und es gibt keinen internen Überlauf). Dann hohlst du dir das Element am Punkt der Liste und setzt es einfach per setZustand etc.

 

[njans]

Volvagias Vorschlag ist definitv gut.
Alternativ könnte man mit den statischen Zuständen auch einfach in der schalteWeiter() Methode schauen, welcher Zustand momentan dran ist, und dann zum nächsten Schalten, wenn man die Implementation mit der Liste nicht möchte

 

[tfa]

Deshalb hohlst du dir einfach den momentanen Zustand der Superclass mit get im wechsle, und setzt mit set den nächsten.

Die Zustandsklassen sollten dafür verantwortlich sein, den Zustand der Ampel zu ändern. Die Klasse Rot weiß z.B. dass nach ihr ("rot") der Zustand "rotgelb" kommt und liefert in ihrer wechsel()-Methode einfach das entsprechende RotGelb-Objekt zurück. Das Ampel-Objekt (der Kontext) muss einfach den wechsel()-Aufruf an ihr aktuelles Zustands-Objekt delegieren. Keine Listen, kein instanceof, kein switch oder lange if-else-if-Orgien. Ganz einfach.

 

[Volvagia]

Verkettete Klassen klingen interessant. Aber wie würdest du dann handlen, welches wirklich nach welcher kommt, also das bei der Fußgänger nicht nach Rot Rot/Gelb kommt?

 

[tfa]

Fußgängerampel und Fahrzeugampel sind unterschiedliche Automaten also bekommen sie auch unterschiedliche Zustandsklassen. Man könnte die als nicht-öffentliche Nested Classes innerhalb der Ampelklassen realisieren.

 

[Moch]

Also alles was ich oben beschrieben habe, ist (leider) so durch die Aufabestellung vorgegeben. Ich würde es auch gerne anderes implementieren, aber so ist's nun mal. In der Klausur werden sicher auch wieder halbfertige Quellcodes und Konzepte stehen, die man dann verstehen und umsetzen soll.
Genauso ist es bei der Vorbereitungsaufgabe.

Hier hieß es z.B. einfach nur: Achten sie darauf, dass sie für alle Zustände jeweils eigene Klassen definieren, die von der abstrakten Oberklasse Zustand erben.

Dadurch eingegrenz kann ich die Zustände leider nicht einfach in Ampel reinschreiben :-(

Hierbei finde ich leider keinen Ansatz. Auch die bisher genannten Lösungen helfen mir nicht wirklich weiter, da ich nicht tief genug in der Materie bin, dass ich das verstehen würde. Wirklich mit Java programmieren tue ich erst seit zwei Monaten (seit beginn des neues Trimesters eben).

Bei dem uns vorgegebenen Ansantz verstehe ich nicht mal, was diese Zustandsklassen überhaupt sollen -.-
Was soll da rein? (ich meine, ich erstelle doch nicht einfach so ne leere Klasse...)

Da ich nicht weiß, wie ich mit diesen Klassen umgehen soll, kann ich natürlich auch die schalteWeiter-Methode nicht implementieren.

Antworten bekommen wir dazu ebend nicht, weil es eine Klausurvorbereitung sein soll, wobei sich hier aber recht viele ziemlich "in der Luft hängen gelassen" fühlen-

 

[njans]

Nun wenn die Aufgabe es aber so verlangt, dann packst du in die Mutterklasse "Zustand" einfach eine Methode gibNamen() und die Überschreibst du dann einfach für jede Subklasse so, dass sie den Namen des Zustandes (z.B. "Grün") ausgibt.

Edit: Der Zustand kann dann jedoch weiterhin von der den Ampeln als Variable gehalten werden.
Somit musste beim weiter schalten nur den Zustand auf den nächsten setzen.

Es wäre auch möglich in die Zustandsklassen eine Methode gibNaechsten() einzubauen, die dann den nächsten zustand zurückgibt. Dann müsste man jedoch für jede Ampel jeweils andere Subklassen schreiben-

 

[Moch]

@njans: Also ich versuch's mal, ob ich es verstanden habe, okay?

1. ich deklariere in der Klasse Zustand eine Methode gibName(): String
2. jede Unterklasse gibt ihren Farb-String in dieser Methode zurück
3. die jeweilige schalteWeiter(): void fragt dann den String ab und greift auf eine Methode gibtNaechsten() zu?

lieben Gruß
Moch