Java Stringに静的な文字列操作メソッドがないのはなぜですか？

Javaデザイナーがjava.lang.Stringクラスで文字列操作メソッドの静的バージョンを作成しなかったのはなぜですか？以下のメソッドは私が参照するものですが、質問はクラス内の他の非静的メソッドにも拡張できます。

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)

これらのメソッドの非静的バージョンのみを使用すると、そのようなメソッドを呼び出さなければならない場所で明示的な nullチェックが強制されます。たとえば、単に呼び出すexample = example.trim()と、NullPointerException ifになりString example = nullます。そのため、プログラマは次の定型的なヌルチェックを行う必要があります。

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

入力文字列を最初の引数としてとるStringこれらのメソッドの静的バージョン（おそらく排他的）があれば、はるかに便利だったと思います。

example = String.trim(example);
example = String.replace(example, 'a', 'b');
example = String.substring(example, 5);

これにより、プログラマーが明示的にnullのケースを処理することを強制するのではなく、nullを返すだけで自動的にnullのケースを処理するプログラマーによって記述されたよりクリーンなコードになります。ヌルの返却は操作以来、私には理にかなってヌル文字列が生じるはずであるヌル文字列ではなく、エラーが発生しました。

StringJava 1またはJava 2でクラスを設計したときに、Javaデザイナーがこれを考えなかったのはなぜですか。また、後のJavaバージョンでそのような機能を追加したのでしょうか。

null文字列を操作するとエラーではなくnull文字列になるはずなので、nullを返すことは理にかなっています

まあ、それはあなたの意見です。他の人は、文字列を含まないヌルオブジェクトの文字列操作は意味がなく、したがって例外をスローする必要があると主張するかもしれません

「Javaデザイナー」が何かをしたのか、しなかったのかを答えるのは難しい。

Apache CommonsのStringUtilsなど、nullセーフな文字列操作を実行できるライブラリが既にあります。必要に応じて、そのライブラリまたは同様のライブラリを使用できます。

コメントに基づいた追加

コメントを読んで、あなたが直面している本当の問題はnull、コード全体をチェックする必要があるということです。これは、インターフェイス間で明確に定義されたコントラクトがない場合のプログラム設計の不良の指標になる可能性があります。Javaでの「！= null」ステートメントの回避をお読みください。

IMOは、メソッドを記述する「引数がnullの場合はnullを返す」というアプローチ全体で、プログラムの循環的な複雑さを不必要に増加させます。

初期のJavaライブラリはnullを返すアプローチを使用していましたが、JDKのスタッフは例外を使用して常にnullから保護していました。

時間が経つにつれて、後者のアプローチが明確な勝者として出てきたと思います。

どうして？nullフィールドは多くのoo原則を破るので。それらを単に多相クラスのメンバーとして扱うことはできません。これは、nullの特別な場合を常にコーディングする必要があることを意味します。したがって、nullになる可能性があると仮定する必要がある場合、循環的な複雑さが急上昇します。

問題を解決するために、nullフィールドに依存するのではなく、nullオブジェクトパターンの使用を検討してください。

これは理由ではありませんが、toStringを除き、これらのメソッドはすべて静的ヘルパークラスに簡単にカプセル化されますが、その逆は当てはまりません。

つまり、Stings.toUpper（string input）が必要な場合、そのためのコードは簡単に記述できますが、instance.toUpperが必要な場合、String.toUpperだけが必要な場合、拡張メソッドを導入しない限り、それはおそらく当時も考慮されていなかったでしょう。

Javaでは、その文字列はオブジェクトです。それは設計上の選択です。

オブジェクト参照はnullになる場合があり、オブジェクト参照が割り当てられていない場合はnullになります。このようなオブジェクトを呼び出すと、NullPointerExceptionがスローされます。これが標準的なoo-behaviourです。

Javaデザイナーは、文字列をオブジェクトとして選択し、文字列をオブジェクトにしたい場合にnullポインタ例外をスローするメソッドを選択しました。

Java 1またはJava 2でStringクラスを設計したときに、Javaデザイナーがこれを考えなかったのはなぜですか。さらに、後のJavaバージョンでそのような機能を追加しましたか？

彼らはおそらくそれについて考え、oo-behaviourを組み込むことを選んだでしょう。