Inputs prüfen

[Zet]

Hallo zusammen,

ich versuche mir derzeit eine Bibliothek zusammenzubauen, in der ich Input-Prüfungen sammel.
Während ich also die verschiedenen Methoden zusammenbastelte, stelle ich mir folgende Frage:

Ich habe diverse Methoden a'la getUpperLetters, hasUpperletters, hasOnlyLetters, isParsableToInt, isParsableToDouble....

nun kam ich bei getInt(String string) an, welche mir den numerischen(int, Double) wert zurückgeben sollte.
Zuerst müsste ich sicherstellen das der übergebene String parsable ist, dazu habe ich ja bereits eine Funktion: boolean isparsabletoInt(String string) - boolean isParsableToDouble(String string).

Ich habe einfach keine Vorstellung, wie das in der Praxis aussieht, und habe das Gefühl ich gehe da ganz falsch ran.


nun würde die Methode ca so aussehen:

static private int getInt(String string)
	{
		if (isParsableToInt(string) == true)
		{
			return Integer.parseInt(string);			
		}
		System.out.println("getInt fehlgeschlagen");
		return 0;
	}

Nun die Frage dazu;
Würdet ihr hier z.B isParsableToInt in der Methode nocheinmal neu definieren(rad nochmal neu erfinden), oder die isParsableToInt-Methode einfach aufrufen? Dann müsste ich ja auch sicherstellen das wenn getInt verwendet wird, die isParsableToInt-Methode implementiert wird. --> Interfaces?
ich müsste ja auch prüfen ob evtl ein Double eingegeben wurde, oder sonstiges.
// es geht mehr um den Aufbau der Bibliothek und der Methoden, als um die Logik der prüfungen selbst.


Ich frage deshalb, weil ich das gefühl habe das ich wenn ich so weitermache, meine Methoden wieder ewig aufblähe und die Bibliothek nicht wirklich nutzbar wird.

Ich meine, später wird man ja wahrscheinlich sowieso einfach String.getInt() aufrufen, und eine rückmeldung bekommen mit dem int-Wert oder eine Rückmeldung das die Funktion fehlgeschlagen ist.
Oder gehe ich an die ganze Sache falsch heran????:L???:L???:L

Grüße
Zet


edit: der Code von isParsableToInt:

static private boolean isParsableToInt(String string) 
	{
		try 
		{
			Integer.parseInt(string);
			System.out.println("isParsableToInt:" + string + " ist eine int-parsbare Zahl");
			return true;
		} 
		catch (NumberFormatException nfe) 
		{
			System.out.println("isParsableToInt: " + string+ " ist keine int-parsbare Zahl");
			return false;
		}
	}

 

[Zet]

Also so langsam habe ich mich komplett verwirrt.
Kann mir jemand sagen wie so eine sammlung von Methoden die man häufig benötigt aussieht,
quasi eine Utility-Klasse?

So wie ich das gemacht habe, muss es eigentlich falsch sein.

Kurz zusammengefasst ist das Ziel sicherzustellen das der input z.B einer GUI eine Zahl ist, und diesen zurückzugeben:
String eingabe = "123";
eingabe.getInt(); --> gibt den Integer-Wert zurück, falls parse nicht möglich fehler.
eingabe.getDouble() --> selbes Spiel


Ich denke jeder hat wohl so eine eigene Utility-Klasse, mit der er arbeitet um alltägliche Methoden wie
Input-validierungen durchzuführen, nur krieg ich das einfach nicht gebacken. :bahnhof:


// Sorry für Doppelpost, aber kann meinen 1. Beitrag nichtmehr editieren.

Grüße
Zet

 

[Flown]

Ich weiß jetzt nicht ob das so sinnvoll ist was du da machst. Ich würde einfach mit

Integer.parseInt()

arbeiten, da wenn die Eingabe so und so keine Zahl ist das abfangen kannst (in deinem Fall musst). Dann hast du eben einen try/catch-Block und verfährst dann wie du wünscht weiter.

 

[Natac]

Also erstmal: String ist eine finale Klasse, die du nicht ändern kannst. Und da es auf String kein getInt() gibt, wirst du auch keines einfügen können.

Eine Util-Klasse sieht bei mir so aus:

public final class XxxUtil{
  
  private static final CONSTANT_1 = ...;
  private static final CONSTANT_2 = ...;

  private XxxUtil(){}

  public static A utilMethod1(B b, C c){ ... }

  public static A utilMethod2(B b, C c){ ... }

}

Ich habe sogar eine util-Bibliothek, wo ich für fast jeden Typ eine Util-Klasse habe, die ich eben in meheren Projekten nutze.

Allgemein würde dir empfehlen solche Methoden so allgemein wie möglich zu halten. Mein Vorschlag für die

toInt(String s)

-Methode:

public int toInt(String s, int defaultValue){
  try{
    return Integer.parseInt(s);
  }
  catch(NumberFormatException e){
    return defaultValue;
  }
}

Falls deine

isParsableToInt(s)

OHNE Exception auskommt, dann würde ich die natürlich vorher aufrufen. Aber wenn du eh nur guckst, ob da parsen funktioniert, dann kannst du den Rückgabewert auch direkt verwenden.

Willst du keinen Default-Wert nutzen, dann würde ich dir drigend raten eine Exception zu werfen.



Denn woher willst du denn wissen, ob der Nutzer "X" oder "0" eingegeben hat, wenn du 0 als Zahl zurückbekommst? Und dein Nutzer wird sich ganzschön umgucken, wenn du einfach mit 0 weitermachst. Also entweder Exception, oder default wert übergeben, aber nie in der methode selbst festlegen.

 

[Zet]

Danke für die Antworten.

Also ist meine isParsableToInt-Methode soweit schon in Ordnung?
Es ging auch weniger um das "wie" die Methoden prüfen, sondern eher wie ich den Aufbau auf die reihe kriege.

Ich habe wirklich dämlich formuliert was das Problem ist.

Hintergrund war folgender, das ich zum x-mal User-Eingaben über eine GUI geprüft habe,
das sie eine Zahl ist, das sie.... ist und .... ist, verschiedene Prüfungen eben.

Bisher habe ich immer den Quelltext neu geschrieben,
da dachte ich mir legst dir mal eine Bibliothek an, wo du deine Methoden ein wenig sortiert hinterlegen kannst - und Später einfach diese aufrufst

Also fing ich an die Methoden zu sammeln, und möglichst allgemein zu schreiben.
Doch dann kam mir das ganze spanisch vor(erster Beitrag), weil es einfach eine riesige Klasse mit verschiedenen Methoden war, und ich den Methodenaufruf Variable.checkSomething
und nicht checkSomething(variable).

An diesem Punkt angelangt, wusste ich nichtmehr wo oben und unten ist - und habe hier nach einer Lösung gesucht.

Ich dachte eben ich erstelle mir eine Art Werkzeugkiste, in der ich meine verschiedenen Werkzeuge ablege und bei bedarf raushole, nur am ende hatte der hammer ein sägeblatt als Stiehl

dann eben back to the roots


Grüße
Zet

 

[Flown]

Andere Möglichkeit wäre das du einen [JAPI]Scanner[/JAPI] verwendest. Das ist einfach und schön und kannst einfach

sc.hasNextFloat();

oder was auch immer prüfen und dann gleich danach parsen.

 

[Zet]

Danke, das werde ich probieren.

Vielen Dank nochmal an alle!


Grüße
Zet