Effektive args[] Behandlung

[_Smash_]

Hallo,

Mein Problem ist folgendes:
Man stelle sich vor man hat ein Programm, welches per Argumente gefüttert werden kann.
Zum Beispiel:
java -jar programm.jar -name="Muster Mustermann" -institut=musterinc -strasse=musterstrasse

Nun hat man möglicherweise einen Rattenschwanz von 10 Argumenten und mehr in der args[] stehen.
Wenn ich diese nun verarbeiten will, dann muss ich ja pro Argument rausfinden, um welches Argument es sind handelt, damit ich den Wert davon in die entsprechenden Funktionen umleiten kann.
Und hier ergibt sich meine Frage. Wie mache ich das besonders effektiv?
Ich könnte wohl jedesmal mit if abfragen ob das ein bestimmtes Statement ist. Bei 10 Argumenten und 15 möglichen Argumenten sind das eine menge Schleifendurchläufe und eine menge "if"s.
Die switch-Anweise funktioniert leider nicht mit Strings.

Wie behandelt ihr also möglichst effektiv Argumente?


Danke
Grüße
Norman

 

[Marco13]

Spontaner Gedanke war eine Map -

Map<String, String> valueMap = ...
for (alle args)
{
    String arg = ...
    String vorDemGleichheitszeichen = abschneidenVon(args);
    String nachDemGleichheitszeichen = abschneidenVon(args);
    valueMap.put(vorDemGleichheitszeichen, nachDemGleichheitszeichen);
}

aber ob das für dich passt müßtest du überlegen - vielleicht hat ja jemand noch andere (bessere) Ideen.

 

[_Smash_]

Danke erstmal für deine Antwort.

Deine Map ordnet ja jetzt zwar den Wert dem Argument zu, aber wie sortierst du sie ein?
Du musst ja sagen

if(argument.equals("name")
{
tue dies;
}
if(argument.equals("strasse")
{
tue das;
}

und das für vieleicht 10 und mehr Fallunterscheidungen/Argumente.
Und das wollte ich quasi effektiv hinbekommen.

Grüße
Norman

 

[SlaterB]

wenn du 10 unterschiedliche 'tue das' hast,
dann brauchst du auch 10 Codestellen und irgendeine Art der Unterscheidung,
was sperrst du dich also dagegen?

um auf dein switch zurückzukommen:
schreibe alle erwarteten Parametertypen in ein Array,
dann für jedes Argument:
durchlaufe das Array der erwarteten Parametertypen, und erhalte so den Index, 0-9 oder unbekannter Parameter
über 0-9 kannst du dann switchen,

vielleicht verwendest du gar eine Enum der Parameternamen


"else if equals" ist aber nur eine Zeile, mit Klammern vielleicht 3, viel kürzer gehts gar nicht

 

[_Smash_]

wenn du 10 unterschiedliche 'tue das' hast,
dann brauchst du auch 10 Codestellen und irgendeine Art der Unterscheidung,
was sperrst du dich also dagegen?

Ich sperre mich nicht dagegen. Ich frage nur, welche Art der Unterscheidung die effektivste ist.
Es verbraucht nunmal eine Menge unnützer Rechenzeit zum 20. mal abzufragen, ob ein Argument "-name" ist, oder nicht.

um auf dein switch zurückzukommen:
schreibe alle erwarteten Parametertypen in ein Array,
dann für jedes Argument:
durchlaufe das Array der erwarteten Parametertypen, und erhalte so den Index, 0-9 oder unbekannter Parameter
über 0-9 kannst du dann switchen,

vielleicht verwendest du gar eine Enum der Parameternamen


"else if equals" ist aber nur eine Zeile, mit Klammern vielleicht 3, viel kürzer gehts gar nicht

Es geht mir nicht um Kürze, sondern Ausführungsgeschwindigkeit.
Dein Vorschlag ist zwar logisch einfach, enthält aber doch dann intern 2 Suchläufe (Arraysuche und Switch).

 

[Wildcard]

Es geht mir nicht um Kürze, sondern Ausführungsgeschwindigkeit.

Was denkst du denn wie lange 20 Stringvergleiche dauern? :shock:

 

[_Smash_]

Es geht mir nicht um Kürze, sondern Ausführungsgeschwindigkeit.

Was denkst du denn wie lange 20 Stringvergleiche dauern? :shock:

Daß es nicht lange dauert heißt ja nicht, daß es nicht noch schneller geht.
Außerdem sind es bei 10 Argumenten schonmal 55 Vergleiche, bei 15 schon 120, bei 20 schon 210... ich denke man sieht wo das hinführt.

 

[SlaterB]

> Es verbraucht nunmal eine Menge unnützer Rechenzeit zum 20. mal abzufragen, ob ein Argument "-name" ist, oder nicht.

von solchen Besonderheiten war bisher noch gar nicht die Rede,
wenn du dazu was diskutieren willst, dann musst du schon näher erläutern worum geht/ was für Parameter und Argumente du hast

> Dein Vorschlag ist zwar logisch einfach, enthält aber doch dann intern 2 Suchläufe (Arraysuche und Switch).

bei so wenigen Elementen ist alles andere als ein String-Vergleich fast schon automatisch langsamer, da jede klitzekleine Sonderstruktur ein Minimum an Zeit zum Aufbau benötigt,
ich dachte zunächst, es ging dir nur um eine saubere, kurze Struktur (Lesbarbarkeit, Änderbarkeit, Fehler-Sicherheit)

die Stringvergleiche könntest du dir sparen,
wenn du vorher eine HashMap der Strings aufbaust,
String -> Integer

und der Switch nach int dauert dann nahezu keine Zeit, weniger als ein Stringvergleich/ Hashcode-Berechnung

 

[_Smash_]

Entschuldigung, ich dachte mein Anliegen, wie ich Argumente behandeln möchte, wäre aus Post 1 und 3 klar geworden. Eigentlich sollten Argumente ja auch immer recht gleich behandelt werden, weil ja jede Art von Schalterargument im Prinzip gleich behandelt werden müsste.
Finde raus was für ein Schalter es ist und handle entsprechend.

Das mit der HashMap hört sich gut an. Das werde ich mal verfolgen.

Weisst du zufällig, wie in diese Klasse (Hashmap) intern die Suche nach dem Key beim späteren Auslesen des Value bewerkstelligt?
Also quasi welche Form der Suche diese Klasse nutzt?


Grüße
Norman

 

[SlaterB]

na Hash eben,
aus dem String den HashCode berechnen (alle char-Werte mit unterschiedlichen Faktoren zusammenzähle),
aus dem HashCode einen ArrayIndex berechnen,
das dortige Element zurückgeben, falls es das gesuchte ist (equals),
falls mehrere String den gleichen Index (Hash) haben, dann die weiteren Elemente mit diesem Index (Hash) anschauen

 

[Gast]

du kannst auch enums verwenden und dann per in deinem switch wieder ein enum draus basteln.

switch(BefehlEnum.valueOf(args)){
case BEFEHL1:
.....
}

 

[NTB]

Ich habe mir die gleiche Frage wie Smash auch schon öfter gestellt.
Insbesondere wird es spannend, wenn man nun Schalter mit und ohne Argumenten hat. Da muss man dann ja auch irgendwie parsen etc. Aber anscheinend hat da jetzt keiner die Superpatentlösung

 

[SlaterB]

Patentlösungen, also fertige Frameworks gibts übrigens sicherlich auch,

und was ist bei den Schaltern so schwer? anfangs sind alle false,
wenn ein Parameter gefunden wird, dann auf true setzen,

wichtig: nicht für jeden internen Schalter mühsam alle String-args von neuem durchsuchen,

sondern von String-args ausgehen, jeden String genau einmal in einen Enum oder int umwandeln und dann ratzfatz verarbeiten

 

[NTB]

Ich habe gerade mal geschaut, wie das bei Apache Axis (hatte ich gerade zur Hand) gelöst ist: Die haben einen recht aufwändigen Parser geschrieben, der dann aber daraus bequeme Objekte mit ID und dann den Paramatern bildet. Anhand der ID wird dann in der entsprechenden Anwendung per Switch-Case entschieden.
Also im Prinzip auch, was hier vorgeschlagen ist.

 

[Guest]

wichtig: nicht für jeden internen Schalter mühsam alle String-args von neuem durchsuchen,

Wie man genau DAS möglichst elegant macht ist ja doch von Anfang an die Frage gewesen .

 

[_Smash_]

sondern von String-args ausgehen, jeden String genau einmal in einen Enum oder int umwandeln und dann ratzfatz verarbeiten

Jo, aber im Prinzip ist das warscheinlich durch die internen Vergleiche und Aufbau der Objekte und Strukturen oder Berechnung von Hashes nicht viel schneller also einen langen Schwanz von "if"s zu durchwühlen, es ist nur wartbarer.
Ich meine die HashMap muss ja auch intern nach dem String suchen, von dem ich den Int-Wert haben will.

Ok, wie gesagt ich werde die Hashtabel mal nehmen.

 

[hupfdule]

Patentlösungen, also fertige Frameworks gibts übrigens sicherlich auch,

z.B. Jakarta Commons CLI