Почему в 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)

Наличие только нестатических версий этих методов вызывает явную проверку нуля везде, где должен вызываться такой метод. Например, простой вызов example = example.trim()приведет к NullPointerException, если 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);

Это привело бы к более чистому коду, написанному программистами, который автоматически позаботился бы о нулевых случаях, просто возвращая ноль, вместо того, чтобы заставлять программистов явно обрабатывать нулевые случаи. Возвращение нуля имеет смысл для меня , так как манипулирования нулевой строки должна привести к нулевой строке, а не об ошибке.

Почему разработчики Java не думали об этом, когда разрабатывали Stringкласс в Java 1 или Java 2, или даже не добавляли такую ​​функциональность в более позднюю версию Java?

Возвращение нуля имеет смысл для меня, так как манипулирование пустой строкой должно привести к пустой строке, а не к ошибке

Ну, это ваше мнение. Другие могут утверждать, что операции String над нулевым объектом, который не содержит String, не имеют смысла и, следовательно, должны выдавать исключение

Почему «дизайнеры Java» сделали или не сделали что-то, трудно ответить.

Уже есть библиотеки, которые могут выполнять операции String с нулевой безопасностью, например StringUtils из Apache Commons. Вы можете использовать эту или аналогичные библиотеки, если они вам нужны.

Дополнение на основе ваших комментариев

Читая комментарии, кажется, что реальная проблема, с которой вы сталкиваетесь, заключается в том, что вы должны проверять nullвесь код. Это может быть индикатором плохого дизайна программы без четко определенных контрактов между интерфейсами. Возможно, вы захотите прочитать Избегание «! = Null» операторов в Java?

ИМО весь подход "если аргумент равен нулю, возвращает ноль" к написанию методов без необходимости увеличивает цикломатическую сложность вашей программы.

Ранние Java-библиотеки использовали метод return null, но ребята из JDK всегда защищали от null с исключениями.

Со временем я думаю, что последний подход стал явным победителем.

Почему? Так как нулевые поля нарушают многие принципы. Вы просто не можете относиться к ним как к членам полиморфного класса. Это означает, что вы всегда должны кодировать особые случаи для нуля, и, следовательно, ваша цикломатическая сложность возрастает, когда вы должны предположить, что вещи могут быть нулевыми.

Чтобы решить ваши проблемы, рассмотрите возможность использования шаблона нулевого объекта вместо использования пустых полей.

Не говоря уж об этом, но за исключением toString, все эти методы легко инкапсулируются в статический вспомогательный класс, тогда как обратное неверно.

Т.е. если вы хотите Stings.toUpper (строковый ввод), то код для этого легко написать, но если вы хотите instance.toUpper и все, что у вас есть, это String.toUpper, ну, это невозможно ... если они не вводят методы расширения, который, скорее всего, даже не рассматривался в то время.

В Java эта строка является объектом. Это выбор дизайна.

Ссылки на объекты могут быть нулевыми и равными нулю, если для него не назначен объект. Если вы вызываете такой объект, генерируется исключение NullPointerException. Это стандартное поведение.

Java-дизайнеры сделали выбор иметь строки в качестве объекта, а те методы, которые генерируют исключения с нулевым указателем, - это то, что вы получите, если хотите, чтобы строки были объектами.

Почему разработчики Java не думали об этом, когда они разрабатывали класс String в Java 1 или Java 2, или даже добавляли такую ​​функциональность в более позднюю версию Java?

Они, наверное, думали об этом и решили включить в себя oo-поведение.