Input/Output Problem bei der Benutzereingabe eines Befehls

DagobertDuck

Bekanntes Mitglied
Guten Abend,

ich habe gerade ein Problem bei meiner Befehlseingabe entdeckt, welches ich einfach nicht behoben bekomme.

Hier wird der eingegebene Befehl erkannt und weiterverarbeitet:
Java:
 while (running) {
            String input = Terminal.readLine();
            try {
                final List<Command> commands = CommandParser.initialiseCommands();
                final List<String> inputSplit = Arrays.asList(input.split(" "));
                final Command command = commands.stream()
                        .filter(cmd -> (input.startsWith(cmd.getName()) && (input.length() == cmd.getName().length()
                                || input.charAt(cmd.getName().length()) == ' ')))
                        .findAny()
                        .orElseThrow(() -> new InvalidInputException("unknown command"));
                final List<String> arguments = CommandParser.getArguments(inputSplit, command);
                if (command.getNumberOfArguments() > 0) {
                    command.setArguments(arguments);
                }
                command.setSession(this);
                command.execute();
            } catch (InvalidInputException e) {
                Terminal.printError(e.getMessage());
            }
        }

Und hier werden die Argumente extrahiert:
Java:
    public static List<String> getArguments(final List<String> inputSplit, final Command command)
            throws InvalidInputException {
        int commandCount = command.getName().split(" ").length;
        final List<String> arguments = inputSplit.subList(commandCount, inputSplit.size());
        if (arguments.size() != command.getNumberOfArguments()) {
            throw new InvalidInputException("invalid number of arguments. Expected " + command.getNumberOfArguments()
                    + " arguments of the form '" + command.getCommandDescription() + "'");
        }
        return arguments;
    }

Jede Befehlsklasse hat die Methode getName(). Für den ExitCommand sieht das beispielsweise so aus:
Java:
    @Override
    public String getName() {
        return "exit";
    }

Das funktioniert so im Grund genommen einwandfrei, allerdings werden die Befehle auch angenommen, wenn am Ende beliebig viele Leerzeichen eingegeben werden. Es darf also z.B. "exit " nicht akzeptiert werden. Das ganze ist deshalb so "kompliziert", da es Befehle gibt, die aus ein, zwei, oder drei Wörtern besteht. Beispiele: "exit", "delete rolling stock", "list trains".

Ich wäre über jegliche Hilfe sehr dankbar!

Viele Grüße
 
Java:
cmd.getName().length()
Wenn du den Indexy vom letzten Zeichen holen willst, musst du noch eine Eins abziehen.
 
Java:
charAt(cmd.getName().length())
Wenn du das letzte Zeichen willst, musst du noch 1 subtrahieren.
Er will das Zeichen nach dem Befehl. Entweder die Länge stimmt überein oder es kommt ein Leerzeichen. Also entweder ist die Eingabe "befehl" oder es ist "befehl irgendwas".

Die fachliche Problematik verstehe ich nur nicht. Wieso ist ein "exit " falsch und darf nicht als "exit" ausgewertet werden?
Aber wenn Du sowas hast: Spielt die Anzahl der Leerzeichen eine Rolle? ==> Du kannst doch einfach die Anzahl der Leerzeichen am Ende der Zeile zählen. Dann hast Du die Anzahl zum Auswerten und kannst auch einen Fehler ausgeben.
 
Die fachliche Problematik verstehe ich nur nicht. Wieso ist ein "exit " falsch und darf nicht als "exit" ausgewertet werden?
Aber wenn Du sowas hast: Spielt die Anzahl der Leerzeichen eine Rolle? ==> Du kannst doch einfach die Anzahl der Leerzeichen am Ende der Zeile zählen. Dann hast Du die Anzahl zum Auswerten und kannst auch einen Fehler ausgeben.
Ich verstehe es auch nicht. Leider wird das so gefordert.
Vielen Dank, ich habe es jetzt so gelöst:
Java:
if (arguments.size() != command.getNumberOfArguments() || input.substring(input.length() - 1).equals(" ")) {
Auch wenn das nicht wirklich schön ist.
 
Du hast jetzt ausgeschlossen, dass es Leerzeichen am Ende gibt. Wenn es generell ausgeschlossen sein soll, dann wäre es aus meiner Sicht einfacher lesbar, wenn man das als eigenen Check einbaut. Und das kannst Du dann ja schon komplett am Anfang prüfen, ehe alle anderen Prüfungen erfolgt sind.

So der Plan ist, "Geheimbefehle" zu haben - also bei einem exit raum muss man "exit " eingeben, damit man raus kommt aus dem Raum und auf die 5 Leerzeichen muss der Spieler erst einmal kommen, dann wird so eine Prüfung schwierig. Da würde ich den Code aber auch schlicht aufteilen:
a) Prüfen der Befehle -> da kann dann auch ein "exit " gefunden werden.
b) Jetzt erst kommt der Split der Argumente und das nicht auf die Eingabe sondern bezogen auf die Eingabe ohne den Befehl und ohne den ersten Trenner.

Das ist aber auch ein Aufbau, der mir nicht gefällt. Was für Befehle aus mehreren Worten habt ihr denn? Denn jetzt spielt plötzlich die Reihenfolge eine Rolle: Wenn "exit" vor "exit " geprüft würde, dann wäre der Befehl wieder nur "exit". So einen Fall sollte es nicht geben wenn es vermeidbar wäre. Dann wäre der Stream auch prädestiniert für ein paralleles ausführen würde ich sagen.

Aber evtl. kannst Du ein paar Beispiele für Befehle mit 3 Wörtern geben oder die genauen Anforderungen?
 
Ja, war vielleicht blöd ausgedrückt Aber mir ging es um eine aussagekräftigen Ausschnitt.

Die bereits gebrachten Beispiele haben mich bisher bestätigt, dass es doch eigentlich um einen Befehl geht und der Rest ist Parameter.

Der Befehl "delete" erwartet Parameter, die definieren, was gelöscht werden soll.
Der Befehl "list" erwartet einen Parameter, was aufgelistet werden soll.

Aber bei der geringen Anzahl an Beispielen ist es in meinen Augen noch nicht aussagekräftig.

Aber es wird schon deutlich: Die Befehle sind so nicht gut definiert. Angenommen der Spieler hat ein Inventar. Dann will man ja nicht einen Befehl "drop xyz" für jeden Gegenstand haben, oder? Da macht es doch mehr Sinn, ein Befehl drop zu haben. Und da wird dann ausgewertet: Gibt es das xyz Objekt? Wo befindet es sich und hat es die Aktion "drop". (Also ist es im Inventar und kann fallen gelassen werden? Oder steht es an einer Position im Raum, so dass es runter gestoßen werden kann? -> Bei einem Textadventure ist es nervig, wenn das richtige Wort gesucht werden muss. Was versteht er denn nun? Da lieber etwas mehr an Möglichkeiten einräumen!)
 
Wenn es generell ausgeschlossen sein soll, dann wäre es aus meiner Sicht einfacher lesbar, wenn man das als eigenen Check einbaut. Und das kannst Du dann ja schon komplett am Anfang prüfen, ehe alle anderen Prüfungen erfolgt sind.
Es soll allerdings dieselbe Fehlermeldung zurückgegeben werden, wie bei arguments.size() != command.getNumberOfArguments(). Daher macht es in meinen Augen da schon Sinn.
 
Hier sind mal ein paar Beispielbefehle inklusive Argumente.

Code:
add track (2147483647,0) -> (0,0)
add track (0,0) -> (-2147483648,0)
list tracks
create engine electrical T3 Marie 1 false true
add train 1 T3-Marie
put train 1 at (0,0) in direction 0,-1
put train 1 at (0,0) in direction -1,0
step 1000
delete train 1
add train 1 T3-Marie
put train 1 at (2147483637,0) in direction 1,0
step 10

Die Befehle (ohne Argumente) hierbei sind:
Code:
add track
list tracks
create engine
add train
put train
step
delete train
 
Wobei man da schon sehen kann, dass der Befehl z.B. "add" lautet und das folgende bereits das erste Argument wie "train" oder "track" ist.
 

Zurück
Oben