Perché i designer Java non hanno creato versioni statiche dei metodi di manipolazione delle stringhe nella classe java.lang.String ? I seguenti metodi sono quelli a cui mi riferisco, ma la domanda può essere estesa anche ad altri metodi non statici nella classe.
concat(String) substring(int, int)
replace(char, char) toLowerCase()
replace(CharSequence, CharSequence) toLowerCase(Locale)
replaceAll(String, String) toString()
replaceFirst(String, String) toUpperCase()
split(String) toUpperCase(Locale)
split(String, int) trim()
substring(int)
Avere solo versioni non statiche di questi metodi obbliga esplicito a null-checking ovunque debba essere chiamato un tale metodo. Ad esempio, semplicemente chiamando example = example.trim() verrebbe a NullPointerException se String example = null . Quindi il programmatore deve eseguire il seguente controllo nullo della caldaia:
if (example != null)
example = example.trim();
// OR:
example = (example==null) ? null : example.trim();
example = (example==null) ? null : example.substring(5);
Immaginerei che sarebbe stato molto più comodo se String avesse versioni statiche di questi metodi (forse anche esclusivamente ), che avrebbero preso la stringa di input come primo argomento:
example = String.trim(example);
example = String.replace(example, 'a', 'b');
example = String.substring(example, 5);
Ciò avrebbe portato a un codice più pulito scritto da programmatori che si sarebbero occupati automaticamente dei casi null semplicemente restituendo null, piuttosto che forzare i programmatori a gestire in modo esplicito casi nulli. Il ritorno di null ha senso per me dal momento che la manipolazione di una stringa null dovrebbe risultare in una stringa null , non un errore.
Perché i designer Java non hanno pensato a questo quando hanno progettato la classe String in Java 1 o Java 2, o addirittura aggiunto tale funzionalità in una versione successiva di Java?