Resetting System.in/out

Question

System.out 및 System.in이 변경되지 않도록 최종적으로 수행 한 경우 System.setIn 및 System.setOut의 이유는 무엇입니까? 다음 진술은 모순되지 않습니까?

System.in 및 System.out 직접 접근 방법없이 접근 할 수 있습니다. 하지만 그들은 이 final이기 때문에 직접 다른 스트림으로 리디렉션 할 수 없습니다. 하지만 다른 스트림을 설정하는 방법은 setter 입니다.

final 왜 재설정해도 되나요? 또는 다른 스트림으로 리셋 할 수있게하려면 왜 final을 사용해야합니까? 직접 액세스하는 대신 사용자가 System.getIn()과 System.getOut()을 쓸 수 있도록 허용하지 않겠습니까?

Answer 1

기본적으로 자바 초창기의 디자인 사마귀를보고 있습니다. 필드는 Java 1.0 (아마도 이미 공개 및 최종)으로 존재했으며, 디자이너가 리디렉션하는 방법을 필요로한다는 것을 깨달았을 때 변경하기에는 너무 늦었습니다. 존재하는 거의 모든 단일 Java 프로그램이 손상되었을 수 있기 때문입니다.

자바의 디자인은 항상 다른 것들과의 상위 호환성을 중시 했으므로 Java 1.1에서는 해결 방법으로 set 메소드를 추가했습니다. (비 최종 필드는 디자인상의 결함을 악화 시켰습니다. 예 : 사용 권한 확인).

Answer 2

나는 in, out 및 err에 대한 수업에서 과거 스와핑에 아무런 문제가 없었습니다. 커맨드 라인 클래스를 테스트하는 경우에 유용합니다. set *() 메서드를 사용했는지 아니면 스트림을 직접 설정했는지는 기억이 안납니다. 그러나 쉽게 할 수있었습니다.

Answer 3

setXXX 메쏘드는 일반적으로 가능하지 않은 것들, 즉 최종 변수를 변경하기 위해 VM 내부 마술을 사용합니다. (최종 스트림은 실시간 스트림 주변 단지 래퍼가 있다면 그것은 개인적으로 변하기 쉬워 wrapees와 같은 마법없이 가능할 것이다.) 간단한 비 최종 필드에 비해이 디자인의

장점 :

• 메서드는, 인스톨되고있는 SecurityManager에, 호출 원이 스트림을 변경하기 위해서 필요한 액세스권을 가지고 있을지 어떨지를 확인하는 것을 요구할 수가 있습니다.
  • 쓸 짧다 : 간단 get + set 방법 (및 전용 필드)에 비해

  .

• 마이클이 말했듯이 더 중요한 점은 이전 코드와의 호환성입니다. setXXX 메서드는 나중에 추가되었습니다.