Instanzen vergleichen?

[Moch]

Hallo,
Ich habe folgendes Problem, bei welchem ich absolut nicht weiterkomme -.-

Gegeben sei folgenden Konstruktor:

public Ampel(){
zustaende = new Zustand[4]  //zustaende bereits in der Klasse definiert mit Zustand[] zustaende;
zustaende[0] = new Rot();
zustaende[1] = new RotGelb();
zustaende[2] = new Grün();
zustaende[3] = new Gelb();
startzustand = zustaende[0];
aktuell = startzustand;
}

Rot, RotGelb usw. sind definierte Konstruktoren, die jeweils einer Unterklasse der abstrakten Klassen Zustand abgehören.

In einer Methode schalteWeiter():void muss ich nun durch die Zustände schalten können, was jedoch daran scheitert, dass ich aktuell nicht mehr zuordnen kann... ist es jetzt gerade Rot(), RotGelb()...?

Die equals() in ihrer Grundform funktioniert hier offensichtlich nicht und wie ich sie anpassen könnte, weiß ich nicht.

Zunächst war mein Ansatz, in die Konstruktoren der Klassen Rot, RotGelb usw. einen String einzufügen, der der Namen der jeweiligen Klasse wiedergibt. Damit hatte ich auch ein vergleichbares Objekt. Eine spätere Aufgabenstellung jedoch macht die Nutzung solcher Objekte unmöglich.
Folglich stehe ich wieder vor dem Anfangsproblem:

Wie kann ich feststellen, welchen der Zustände "aktuell" gerade verkörpert?

lieben Gruß
Moch

 

[MOEP_BIBER]

Ich denke dass geht mir der Methode instanceOf().

 

[Marcinek]

Oder eine Methode aus

Zustand

 

[Moch]

An instanceOf hatte ich auch schon gedacht, jedoch hat es nicht funktioniert.
Das Problem hier ist, dass es später verschiedene Ampeln geben wird, die eine unterschiedliche Anzahl an Zuständen haben
- Fussgänger mit lediglich rot/grün
- KfZ mit rot/rotgelb/grün/gelb

gemäß Aufgabenstellung ist es nicht erlaubt, die schalteWeiter() in den Unterklassen wieder zu überschreiben.

Daher kann ich hier nicht einfache eine Abfrage

if (aktuell instanceof Rot)

schreiben, da dies nicht mehr allgemeingültig wäre. Bei der FahrzeugAmpel wäre der FOlgezustand rotgelb und bei einer FußgängerAmpel wäre der Folgezustand grün.

Ich wollte hierbei, wenn möglich explizit mit den Index-Werten des Arrays arbeiten können.

 

[njans]

Marcinek meint soetwas:

public String gibZustandstyp()
{
      return "Rot"; 
      // Das würde so zum Beispiel für Rot aussehen.
      // Natürlich müsstest du diese Methode von jeder Subklasse überschreiben und etwas anderes zurückgeben
      // Wenn du jedoch bereits einen passenden String, int, was auch immer hast, der auch in der Superklasse vorhanden ist
      // kannst du auch einfach diese variable zurückgeben, die ist dann ja bei allen Subtypen anders.
}

 

[Moch]

Hier tritt wieder genau das Problem auf, das ich bereits in den Aufgabenstellung erwähnte:

Ursprünglich hatte ich mit einem String in jeder der Zustandsklassen gearbeitet und diesen zum Vergleich genutzt.
Dies hat auch bis zu einem bestimmten Punkt sehr gut funktioniert.

Später trat das folgende Problem auf:
- Wir sollen eine AmpelAnlage schreiben (diese erbt von Ampel, besteht aus FussgängerAmpeln und Kfz-Ampeln (beide erben von Ampel)). Hierbei können es endlos viele Ampel sein, die zu einer Anlage zusammengefasst werden.
- Die AmpelAnlage nutzt eine Klasse komponierterZustand, die ebenfalls von Zustand erbt und aus den Zuständen der Ampel besteht (hier nutze ich eine Map mit der jeweiligen Ampel als key und einem Objekt vom Typ Zustand)

Soweit alles noch kein Problem. Einige vorher geschriebene JUnit-Testklassen sollen nun allgemeingültig für sowohl Ampeln, als auch AmpelAnlagen gelten.
Da ich zuvor alle Vergleiche über jene Strings geregelt habe, aber keine eindeutigen String aus dem komponierten Zustand ziehen kann, gelten meine JUnit-Klasse nicht wie gefordert allgemein.

Daher hatte ich die Aufgabe auch (zum dritten Mal mittlerweile -.-) komplett neu angefangen und verfolge nun dieses Konzept.

So langsam weiß ich nämlich auch nicht mehr weiter, wie ich das noch umsetzen soll. Die Aufgabenstellung lässt einerseits den Weg komplett offen, den man wählt, ist dann jedoch durch - teilweise sehr nervige - Bedingungen wieder eingegrenzt...
Ich hätte z.B. die Zustände nicht als eigene Klassen geschrieben, aber das tut nichts zur Sache.

lieben Gruß
Moch

 

[daNny]

Evtl. wäre es hilfreich, wenn du die genaue Aufgabenstellung mal erläutern würdest

Zumindest mir wären die genauen Vorgaben/Restriktionen jetzt nicht klar!

 

[Moch]

Ich werde mal versuchen es kurz zu fassen. Es geht hierbei um unsere Klausurvorbereitungsaufgabe, für die es keine Lösung gibt.

Wie sicherlich schon gesehen, geht es um Ampeln

Es handelt sich hierbei NICHT um die Reihenfolge oder den Wortlaut der Aufgaben

1. Es gibt drei Packages: ampeln, zustandsmaschine, test

2. Ampel ist eine abstrakte Klasse, die die Methode schalteWeiter():void beinhaltet
2.1 FussgaengerAmpel und FahrzeugAmpel sind Unterklassen von Ampel
2.1a schalteWeiter soll in beiden NICHT neu geschrieben werden
2.2 Später kommt die abstrakte Unterklasse AmpelAnlage dazu, die die Ampeltypen kombinieren soll (beliebige Anzahl) (hier darf schalteWeiter überschrieben werden)
2.3 Eine Ampel hat einen fest definierten Startzustand und einen aktuellen Zustand

3. Die Klasse Zustand ist abstrakt
3.1 Ihre Unterklassen sind die möglichen Zustände Rot, RotGelb, Gelb, Grün
3.2 Weitere Unterklasse ist komponierterZustand (fasst mehrere Ampeln und deren aktuellen Zustand zusammen und ist Zustand einer Anlage)
3.2a Sie beinhaltet die folgende Methode mit folgender Signatur
public void addZustand(Object key, Zustand zustand);

4. Im Package tests sollen wir verschiedene JUnit-Tests ablaufen lassen, die sowohl für einfache Ampeln, als auch für Anlagen allgemeingültig sind
4.1 sie prüfen, ob alle Zustände erreicht werden, jeder Zustand einen Nachfolger hat und ob nach einer endlich Anzahl von schalteWeiter()-Aufrufen wieder der Startzustand erreicht wird.
-------------------------------------------------------------------------------------------------
Ursprünglich habe ich damit gearbeitet, dass jeder Zustandsklasse im Konstruktor zwei Strings erzeugt:
String aktuell;
String next;
Aktuell entspricht hierbei immer dem Klassennamen und next konnt entweder default sein (FahrzeugAmpel) oder per Übergabe festgelegt sein.
Entsprechend hatte ich alle Vergleiche über diese Strings laufen lassen und auch die JUnit-Tests über die Strings geschrieben.
Sahen zwar abenteuerlich aus, aber funktioniert... hier ein Beispiel:

if(ampel1.getAktuellerZustand().getAktuell.equals("Rot")) {Anweisungen}

Der KomponierteZustand, von mir als HashMap umgesetzt, jedoch kann keinen solchen String zurückgeben, da er aus mehreren Zuständen besteht.
Foglich waren alle meine Vergleiche, die eben über die Strings liefen, nicht mehr allgemeingültig.

Dadurch habe ich neu angefangen und wollte einen Ansatz wählen, in welchem Strings keine Rolle mehr spielen, was den Vergleich angeht.
Einen String gegen sie jetzt auch noch aus, jedoch nur für mich zu Testzwecken.

Daher war mein Ansatz ein Array aufzubauen, um zunächst die schalteWeiter allgemein zu implementieren ... hierbei scheitere ich jedoch schon daran, dass ich nicht mehr prüfen kann, zu welchem Objekt aktuell gerade gehört.
Baue ich hier wieder einen String ein, renne ich mit dem komponiertenZustand erneut gegen eine Wand, was die Allgemeingültigkeit meiner Vergleiche und meine JUnit angeht.

lieben Gruß
Moch

 

[Gast2]

Hmmm, irgendwie finde ich das Design merkwürdig?

Ampel ist ein abstrakte Klasse, Fußgängerampel und Fahrzeugampel erben davon. Soweit gut. Aber warum ist dann eine Ampelanlage auch eine Unterklasse von Ampel? Und warum wieder abstrakt? Ich würde eher davon ausgehen das eine Ampelanlage ein von Ampel unabhängiges Objekt ist und eine Set von Ampel Objekten vereinigt. Anders macht das wenig Sinn meiner Meinung nach.

Ebenso die Klasse Zustand. Warum wider Unterklassen die Ampeln enthalten? In meiner Sicht der Welt hat eine Ampel einen Zustand und nicht ein Zustand eine Ampel? Das mag vielleicht bei dem Konzept der Ampelanlage gut klingen da der Zustand dann für eine Ampelanlage gilt und somit mehrere Ampeln und ihre Zustände erfasst, aber insgesammt doch recht merkwürdig.

Ich würde eher sagen:
Ampel - Interface oder abstrakte Klasse, jede Ampel hat ein Attribut Zustand (+ evtl Startzustand wenn nötig) und eine Liste gültiger Nachfolgezustände wie ein Automat.
Fußgängerampel, Fahrzeugampel, Bahnampel, etc - konkrete Implementierungen oder Klassen die von Ampel erben

Ampelanlage - Hat als Attribut eine Menge Ampeln, kann ihren Zustand abfragen, gültige Nachfolgezustände und somit alle Ampeln die zu der Anlage gehören schalten. Die sollte auch nicht abstrakt sein. Ich möchte doch eine Ampelanlage erzeugen? Könnt mir jetzt nichtvorstellen welche Klasse ich davon erweitern könnte damit das Sinn macht.

Zustand dann einfach als Enum von Ampelfarben/Signalen.

 

[Moch]

Wie gesagt: Leider ist die Aufgabenstellung NICHT optional und leider genau so vorgegeben. Ich bin davon auch nicht sonderlich begeistert :-( - entspricht nicht dem Stil, mit welchem ich Programme schreibe...
Fakt ist aber: Ich soll es gemäß der Aufgabenstellung umsetzen und die Prüfung wir entsprechend darauf aufbauen bzw. sehr ähnliche Dinge verlangen.

 

[Noctarius]

Die Bezeichner in der Aufgabenstellung sind, abgesehen vom allgemeinen Design, genauso merkwürdig. Wenn schon Jemand Klassennamen mit Umlauten vorgibt (abgesehen von den sonst deutschen Bezeichnern) gehört die Person erschossen -.-

Was du suchst dürfte eine Art kleiner Statemachine sein. Darin kannst du dann Flows definieren. Dann musst du nur die Zustandsübergänge definieren.

Endlicher Automat ? Wikipedia

 

[schalentier]

Das Problem an der Aufgabenstellung ist, dass Zustaende ueber Klassen abgebildet sind. D.h. man kann beliebig viele Rot-Zustaende erzeugen, was jedoch vollstaendig dem Sinn eines Zustands (den gibts nunmal nur genau einmal) widerspricht. Dafuer nimmt man entweder Konstanten (public static final int ROT=1) oder besser Enums.

Wenn du daran nicht ruetteln kannst oder darfst, koenntest du evtl. sowas machen. Aber Vorsicht, dass ist ganz grosser Bockmist:

public abstract class Zustand {
   public boolean equals( Object z ) {
      if( z instanceof Zustand ) {
         return this.getClass()==z.getClass();
      }
      return false;
   }
}

Dann kannste sowas schreiben:

Zustand aktuell = new Rot();

if( aktuell.equals(new Rot()) ) { ... }

Zudem koenntest du eine Methode [c]getNextZustand()[/c] in die Klasse Zustand einbauen

public abstract class Zustand {
   public abstract Zustand getNextZustand();
}
public class Rot extends Zustand {
   public abstract Zustand getNextZustand() {
      return new RotGelb();
   }
}
...

 

[Moch]

Ich möchte mich nochma herzlich für die Hilfe hier bedanken!
Für die Klausur hat unser Ansatz funktioniert bzw. ausgereicht.
Problem war natürlich, dass der Prüfer einen ganz anderen Ansatz gefahren hat, aaber trotzdem hat es gepasst.
Vielen, vielen Dank!

Jetzt geht's an die Übung für das große Programmierprojekt im Herbst