Ein Textadventure AIP Aufgabe Fabian Bergfeld Patrick Boeckhoven Christian Haberland Benjamin Jochheim Liem Nguyen

Entwürfe Dr.Little schlecht,besser Unterschiede schlecht ->besser Erweiterung um hoch, runter Erweiterung Stories 1.0 Statische Sicht Dynamische Sicht Verteilungssicht Fachliche Sicht Erweiterung Stories 2.0 Unterschiede zu Stories 1.0

TODO Hier kommen die Klassendiagramme von Dr.Little schlecht und besser rein

Merkmale von Dr.Little-schlecht

Feste Eingänge -> Erweiterungen sind schwierig Öffentliche Attribute -> InformationHiding class Raum { public String beschreibung; public Raum nordausgang; public Raum suedausgang; public Raum ostausgang; public Raum westausgang class Raum { public String beschreibung; public Raum nordausgang; public Raum suedausgang; public Raum ostausgang; public Raum westausgang

Hohe Kopplung Nicht alle Parameter werden verwendet -> Interface zu breit Schlecht für Erweiterungen -> Parameterliste müsste erweitert Bei mehrmaligen Setzten eines Raumes, kann kein Null mehr für einen Raum gesetzt werden public void setzeAusgaenge(Raum norden, Raum osten, Raum sueden, Raum westen) { if(norden != null) nordausgang = norden;... public void setzeAusgaenge(Raum norden, Raum osten, Raum sueden, Raum westen) { if(norden != null) nordausgang = norden;...

Ausgang Norden und Osten bleiben beim zweiten Aufruf erhalten!!! // Aufruf 1: setzeAusgaenge(ausgangNorden,ausgangOsten, ausgangSueden, ausgangWesten) // Aufruf 2: setzeAusgaenge(null,null, ausgangSueden, ausgangWesten);... // Aufruf 1: setzeAusgaenge(ausgangNorden,ausgangOsten, ausgangSueden, ausgangWesten) // Aufruf 2: setzeAusgaenge(null,null, ausgangSueden, ausgangWesten);... Fehler beim wiederholten Aufrufen. Beispiel:

Direkter Zugriff auf Klassen-Attribute Man muss das innere von Raum kennen -> hohe Kopplung Es kann die Abfrage eines Attributs vergessen werden private void willkommenstextAusgeben(){... if (aktuellerRaum.nordausgang != null) System.out.print("north "); if (aktuellerRaum.ostausgang != null) System.out.print("east "); if (aktuellerRaum.suedausgang != null) System.out.print("south "); if (aktuellerRaum.westausgang != null) System.out.print("west "); private void willkommenstextAusgeben(){... if (aktuellerRaum.nordausgang != null) System.out.print("north "); if (aktuellerRaum.ostausgang != null) System.out.print("east "); if (aktuellerRaum.suedausgang != null) System.out.print("south "); if (aktuellerRaum.westausgang != null) System.out.print("west ");

Feste Befehlsliste -> Feste Bestandteile von Veränderlichen trennen Schlecht für Erweiterung Ausgabe auslagern -> trennen von Blogic (MVC) private void hilfstextAusgeben() { System.out.println("Sie haben sich verlaufen. Sie sind allein."); System.out.println("Sie irren auf dem Unigelände herum."); System.out.println(); System.out.println("Ihnen stehen folgende Befehle zur Verfügung:"); System.out.println(" go quit help"); } private void hilfstextAusgeben() { System.out.println("Sie haben sich verlaufen. Sie sind allein."); System.out.println("Sie irren auf dem Unigelände herum."); System.out.println(); System.out.println("Ihnen stehen folgende Befehle zur Verfügung:"); System.out.println(" go quit help"); }

Wird nur von verarbeiteBefehl() aufgerufen, daher sollte die Schnittstelle kleiner sein (nur den Raum übergeben) private void wechsleRaum(Befehl befehl) { Allgemein für die Klasse Spiel gilt: Klasse sollte sich nur um Spielelogik kümmern, nicht um das Parsen der Eingabe.

Look wird angenommen, obwohl es nicht spezifiziert ist. Dadurch dass look nicht erwartet wird, wird es nicht abgefangen Anweisung wie look ??? wird ausgeführt class Befehlswoerter { // ein konstantes Array mit den gültigen Befehlswörtern private static final String gueltigeBefehle[] = { "go", "quit", "help", "look" }; class Befehlswoerter { // ein konstantes Array mit den gültigen Befehlswörtern private static final String gueltigeBefehle[] = { "go", "quit", "help", "look" };

"Das Befehlswort sollte 'null' sein, wenn dieser Befehl als nicht vom Spiel erkannt gekennzeichnet werden soll. Schlecht: Datenparameter haben eine Doppelbedeutung public Befehl(String erstesWort, String zweitesWort) { befehlswort = erstesWort; this.zweitesWort = zweitesWort;}.... public boolean istUnbekannt() { return (befehlswort == null); } public Befehl(String erstesWort, String zweitesWort) { befehlswort = erstesWort; this.zweitesWort = zweitesWort;}.... public boolean istUnbekannt() { return (befehlswort == null); }

Liefert das Befehlswort (das erste Wort) dieses Befehls. Wenn der Befehl nicht verstanden wurde, ist das Ergebnis 'null'. Schlecht: Datenparameter haben eine Doppelbedeutung Verbesserung: Exceptions im Fehlerfall public String gibBefehlswort() { return befehlswort; } public String gibBefehlswort() { return befehlswort; }

Ausgaben (hier via println) sowie das einlesen via Buffered Reader sollten von dem eigentlichen Parsen entkoppelt werden. public Befehl liefereBefehl() {... System.out.print("> "); // Eingabeaufforderung..... BufferedReader eingabe = new BufferedReader(new InputStreamReader(System.in));..... eingabezeile = eingabe.readLine();... public Befehl liefereBefehl() {... System.out.print("> "); // Eingabeaufforderung..... BufferedReader eingabe = new BufferedReader(new InputStreamReader(System.in));..... eingabezeile = eingabe.readLine();...

Merkmale von Dr.Little-besser

Private wird verwendet -> Attribute versteckt Attribute nur über Getter und Setter zu erreichen gibKurzbeschreibung() gibLangeBeschreibung() setzeAusgang() class Raum { private String beschreibung; private HashMap ausgaenge; // die Ausgänge dieses Raums class Raum { private String beschreibung; private HashMap ausgaenge; // die Ausgänge dieses Raums

Private wird verwendet -> Attribute versteckt Attribute nur über Getter und Setter zu erreichen gibKurzbeschreibung() gibLangeBeschreibung() setzeAusgang() Beliebige Richtung können eingegeben werden (-) Keine Absicherung der Richtung(Dubbleten) public void setzeAusgang(String richtung, Raum nachbar) { ausgaenge.put(richtung, nachbar); } public void setzeAusgang(String richtung, Raum nachbar) { ausgaenge.put(richtung, nachbar); }

Ausgänge werden als HashMap implementiert -> mehrere Ausgänge möglich Nachteile: (-) richtung als String ->Eingabe falscher Ausgänge Abgeschwächt bei Verwendung von StringKonstanten private HashMap ausgaenge; // die Ausgänge dieses Raums.... ausgaenge.put(richtung, nachbar);... private HashMap ausgaenge; // die Ausgänge dieses Raums.... ausgaenge.put(richtung, nachbar);... draussen.setzeAusgang("east", hoersaal); draussen.setzeAusgang(East", labor); Besser: draussen.setzeAusgang(EAST, labor); draussen.setzeAusgang("east", hoersaal); draussen.setzeAusgang(East", labor); Besser: draussen.setzeAusgang(EAST, labor);

Ausgänge werden als HashMap implementiert -> mehrere Ausgänge möglich Nachteile: (-) richtung als String ->Eingabe falscher Ausgänge Abgeschwächt bei Verwendung von StringKonstanten private HashMap ausgaenge; // die Ausgänge dieses Raums.... ausgaenge.put(richtung, nachbar);... private HashMap ausgaenge; // die Ausgänge dieses Raums.... ausgaenge.put(richtung, nachbar);...

TODO Hier kommen die CODE-Stellen der Änderung für hoch + runter In Dr.Little besser rein

Erweiterung von Dr. Little-besser um Stories 1.0

TODO Aufgabe 2

Erweiterung von Dr. Little-besser um Stories 2.0

TODO AUFGABE3