많은 DataInputStream을 덤핑하는 것이 좋지 않습니까?

Question

3 차원 벡터를 보유하는 데이터 클래스가 있다고 가정 해 봅니다.

class Vec3 { 
    float x, y, z; 
    public Vec3(float x, float y, float z) { /* ... */ } 
} 

그런 다음 스트림에서 읽을 기능을 제공하려고합니다. 나는 수레가있어서 가장 쉬운 선택은 DataInputStream입니다.

public static Vec3 read(DataInputStream in) { 
    float x = in.readFloat(); 
    float y = in.readFloat(); 
    float z = in.readFloat(); 
    return new Vec3(x, y, z); 
} 

물론 모든 유형을 InputStream 유형으로 지원하고 싶습니다. 따라서 모든 스트림을 래핑하는 오버로드를 생성합니다.

public static Vec3 read(InputStream in) { 
    return read(new DataInputStream(in)); 
} 

그러나이 방법은 결코 폐쇄 그냥 읽은 후 덤프하는 DataInputStream을 만듭니다. 이 나쁜 습관은 문제가 될 수 있습니까? Vec3을 (를) 읽으려면 어떻게해야합니까?

Answer 1

DataInputStream은 자체 리소스가 거의없고 InputStream 이상의가는 래퍼입니다. 해당 close() 메서드는 래핑 된 입력 스트림을 닫습니다. 그것들을 많이 생성한다는 것은 GC가 수집 할 수있는 많은 임시 객체를 생성한다는 것을 의미합니다. 많은 DataInputStream 개체를 생성하고 삭제하는 데 아무런 위험이 없지만 성능을 최적화하려는 경우에는 사용하지 않는 것이 좋습니다.

반면에 모든 입력 스트림 유형을 지원하려는 것은 지나치게 일반화 된 것처럼 보입니다. 나는이 방법이 단지 DataInputStream, 또는 DataInput 인터페이스 만 받아들이도록 만들 것이다.

Answer 2

제가 말할 수있는 한, 당신이 제안한 것은 안전합니다. (당신이 사용되지 않는 readLine 방법을 사용하는 경우 미리 읽기와 잠재적 인 문제가 비록 DataInputStream은 ... 버퍼링을하지 않습니다.)

을하지만, 일시적 DataInputStream 인스턴스를 많이 생성 관련 비용이 있는가, 그래서 만약 당신은 그렇게하지 말아야 할 성능에 신경을 씁니다.

---

그리고, 물론, 나는 그것이 모두의 InputStream 유형을 지원하려면 ....

는 나는 "물론"를 참조하지 않습니다. 성능에 미치는 영향이 있다면 은이 아니어야합니다. 단순히 당신이 있기 때문에 생각하면 누군가 은 아마도 나쁜 생각입니다.

반면에 "편의성"오버로드를 사용할 것인지 여부를 API를 사용하는 프로그래머에게 맡길 수도 있습니다.

Answer 3

서명을 DataInputStream으로 변경하고 호출자가이를 제공하도록합니다. 그렇다면 그들을 보호하는 것은 발신자의 문제입니다 :-)하지만 그는 또한 당신보다 그들을 보전 할 수있는 훨씬 좋은 위치에 있습니다.