Perché Java String non ha metodi di manipolazione di stringhe statiche?

Perché i progettisti Java non hanno creato versioni statiche dei metodi di manipolazione delle stringhe nella java.lang.Stringclasse? I seguenti metodi sono ciò 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 forza il controllo nullo esplicito ovunque un tale metodo debba essere chiamato. Ad esempio, la semplice chiamata example = example.trim()porterebbe a NullPointerException se String example = null. Quindi il programmatore deve eseguire il seguente controllo null sulla piastra di caldaia:

if (example != null)
    example = example.trim();
// OR:
example = (example==null) ? null : example.trim();
example = (example==null) ? null : example.substring(5);

Immagino che sarebbe stato molto più conveniente se Stringavessero avuto versioni statiche di questi metodi (forse anche esclusivamente ), che avrebbe 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 dai programmatori che si sarebbe automaticamente occupato di casi nulli semplicemente restituendo null, piuttosto che forzare i programmatori a gestire esplicitamente casi nulli. La restituzione di null ha senso per me poiché la manipolazione di una stringa null dovrebbe comportare una stringa null , non un errore.

Perché i progettisti Java non hanno pensato a questo quando hanno progettato la Stringclasse in Java 1 o Java 2 o addirittura hanno aggiunto tale funzionalità in una versione Java successiva?

La restituzione di null ha senso per me poiché la manipolazione di una stringa null dovrebbe comportare una stringa null, non un errore

Bene, questa è la tua opinione. Altri potrebbero obiettare che le operazioni String su un oggetto null, che non contiene String, non hanno senso e quindi dovrebbero generare un'eccezione

Perché "designer Java" abbiano fatto o meno qualcosa è difficile da rispondere.

Esistono già librerie là fuori che possono eseguire operazioni String a rischio zero , ad esempio StringUtils di Apache Commons. Puoi usare quella o simili librerie se ne hai bisogno.

Aggiunta basata sui tuoi commenti

Leggendo i commenti, sembra che il vero problema che affronti sia che devi controllare nulltutto il tuo codice. Questo può essere un indicatore di una cattiva progettazione del programma senza contratti chiaramente definiti tra le interfacce. Potresti voler leggere Evitando le istruzioni “! = Null” in Java?

IMO l'intero approccio "if arg is null return null" alla scrittura dei metodi aumenta inutilmente la complessità ciclomatica del tuo programma.

Le prime librerie Java utilizzavano l'approccio null null, ma i ragazzi JDK si sono sempre guardati bene da null con eccezioni.

Con il tempo, penso che quest'ultimo approccio sia diventato il chiaro vincitore.

Perché? Poiché i campi null infrangono molti principi oo. Semplicemente non puoi trattarli come membri di una classe polimorfica. Ciò significa che devi sempre codificare casi speciali per null, e quindi la tua complessità ciclomatica aumenta quando devi presumere che le cose possano essere null.

Per risolvere i tuoi problemi, considera di utilizzare il modello di oggetti null invece di fare affidamento su campi null.

Non dire questo è il motivo, ma tranne toString, tutti questi metodi sono facilmente incapsulati in una classe di supporto statica, mentre il contrario non è vero.

Vale a dire se vuoi Stings.toUpper (input stringa) il codice per questo è facile da scrivere, ma se vuoi instance.toUpper e tutto ciò che hai è String.toUpper, beh, è ​​impossibile ... a meno che non introducano metodi di estensione, che molto probabilmente non era nemmeno considerato al momento.

In Java, quella stringa è un oggetto. Questa è una scelta di design.

I riferimenti agli oggetti possono essere nulli e nulli se non vi è alcun oggetto assegnato. Se si chiama tale oggetto, viene generata una NullPointerException. Questo è un comportamento oo standard.

I progettisti Java hanno fatto la scelta di avere stringhe come oggetto e avere quei metodi che generano eccezioni con puntatore null è ciò che ottieni se vuoi che le stringhe siano oggetti.

Perché i progettisti Java non hanno pensato a questo quando hanno progettato la classe String in Java 1 o Java 2 o addirittura hanno aggiunto tale funzionalità in una versione Java successiva?

Probabilmente ci hanno pensato e hanno scelto di incorporare l'oo-comportamento.