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 if이됩니다 String example = null. 따라서 프로그래머는 다음 상용구 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 사례를 자동으로 처리하는보다 깔끔한 코드가 프로그래머에 의해 작성되었습니다. 널의 반환은 조작 이후 나에게 의미가 널 A의 결과를해야 문자열을 널 문자열이 아닌 오류입니다.

Java 설계자 String가 Java 1 또는 Java 2로 클래스를 설계 하거나 이후 Java 버전에서 이러한 기능을 추가 할 때 이것을 생각 하지 않은 이유는 무엇 입니까?

null 문자열을 조작하면 오류가 아닌 null 문자열이 발생하므로 null 반환은 의미가 있습니다.

글쎄, 그건 당신의 의견입니다. 다른 사람들은 String을 포함하지 않는 null 객체에 대한 String 연산이 의미가 없으므로 예외를 발생시켜야한다고 주장 할 수 있습니다.

왜 "자바 디자이너"가 무언가를했거나하지 않았습니까?

null 안전 문자열 작업을 수행 할 수있는 라이브러리가 이미 있습니다 (예 : Apache Commons의 StringUtils ). 필요한 경우 해당 라이브러리 또는 유사한 라이브러리를 사용할 수 있습니다.

귀하의 의견에 따른 추가

주석을 읽으면 실제로 직면하는 문제는 null코드 전체 를 확인해야한다는 것 입니다. 인터페이스 간의 계약이 명확하게 정의되어 있지 않으면 잘못된 프로그램 설계의 지표가 될 수 있습니다. Java에서 "! = null"문 피하기? 를 읽고 싶 습니까?

IMO 메소드 작성에 대한 "arg가 null return null 인 경우"전체 접근 방식은 프로그램의 순환 복잡성을 불필요하게 증가시킵니다.

초기 Java 라이브러리는 null 반환 방식을 사용했지만 JDK 사용자는 예외를 제외하고 항상 null을 방지했습니다.

시간이 지남에 따라 후자의 접근 방식이 확실한 승자라고 생각합니다.

왜? 널 필드는 많은 OO 원칙을 위반하기 때문에. 단순히 다형성 클래스의 멤버로 취급 할 수 없습니다. 이것은 항상 널 (null)에 대해 특수한 경우를 코딩해야하므로, 널이 ​​될 수 있다고 가정해야 할 때 순환 복잡성이 급증합니다.

문제점을 해결하려면 널 필드에 의존하는 대신 널 오브젝트 패턴을 사용하십시오.

이것이 이유가 아니라 toString을 제외하고 이러한 메소드는 모두 정적 헬퍼 클래스에 쉽게 캡슐화되지만 그 반대는 사실이 아닙니다.

즉, Stings.toUpper (문자열 입력)를 작성하려면 코드를 작성하기 쉽지만 instance.toUpper를 원하고 String.toUpper 만 있으면 확장 메소드를 도입하지 않는 한 불가능합니다 ... 당시에는 고려되지 않았을 가능성이 높습니다.

Java에서 해당 문자열은 객체입니다. 그것은 디자인 선택입니다.

오브젝트 참조는 널이 될 수 있으며 오브젝트가 지정되지 않은 경우 널입니다. 이러한 객체를 호출하면 NullPointerException이 발생합니다. 그것은 표준 oo-behaviour입니다.

Java 디자이너는 문자열을 객체로 선택하고 null 포인터 예외를 발생시키는 메소드를 선택하여 문자열을 객체로 만들 수 있습니다.

Java 설계자가 Java 1 또는 Java 2에서 String 클래스를 설계하거나 이후 Java 버전에서 이러한 기능을 추가 할 때 이것을 생각하지 않은 이유는 무엇입니까?

그들은 아마도 그것에 대해 생각하고 행동을 통합하기로 결정했습니다.