초보개발자 긍.응.성

clone 메서드를 잘 동작하게 해주는 구현 방법과 주의할 점들에 대해 알아보자. Cloneable Cloneable은 복제해도 되는 클래스임을 명시하는 용도의 믹스인 인터페이스이다. 하지만 이 인터페이스는 의도한 목적을 잘 이루지 못하였다. 가장 큰 문제는 clone 메서드가 선언된 곳이 Cloneable이 아닌 Object이고 그 마저도 protected이다. 그렇기에 Cloneable을 구현하는 것만으로는 외부에서 clone 객체를 호출할 수 없다. 그럼에도 불구하고 Cloneable 방식은 많이 사용되고 있기 때문에 알아둘 필요가 있다. Cloneable을 구현한 클래스의 인스턴스에서 clone을 호출하면 그 객체의 필드를 하나하나 복사흔 객체를 반환하며, 그렇지 않은 클래스의 인스턴스에서 호출하..

toString을 잘 구현한 클래스는 사용하기에 훨씬 즐겁고, 그 클래스를 사용한 시스템은 디버깅하기 쉽다. Object의 기본 toString 메서드는 우리에게 적합한 문자열을 잘 반환해주지 않기 때문에 toString의 일반 규약에 따라 간결하면서 사람이 읽기 쉬운 형태의 유익한 정보를 반환하도록 재정의할 필요가 있다. toString 규약 실전에서 toString은 그 객체가 가진 주요 정보 모두를 반환하는 게 좋다. 만약 객체가 거대하거나 객체의 상태가 문자열로 표현하기에 적합하지 않다면 요약 정보를 담아 전달해 줄 수 있어야 한다. toString 포맷 toString을 구현할 때면 반환 값의 포맷을 문서화할지 정해야 한다. 반환 값을 포맷을 문서화하였다면 그 객체는 표준적이고, 명확하게 사람이..

equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 한다. 그렇지 않으면 hashCode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashMap이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제를 일으키게 된다. hashCode 재정의의 필요성 아래의 내용은 Object 명세 규약에 포함된 내용이다. equals 비교에 사용되는 정보가 변형되지 않았다면, 애플리케이션이 실행되는 동안 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 한다. 단, 애플리케이션을 다시 실행한다면 이 값이 달라져도 상관없다. equals(Object)가 두 객체를 같다고 판단했다면, 두 객체의 hashCode는 똑같은 값을 반환해야 한다. equals(Object..

앞서 살펴본 equals 일반 규약들과 이를 위배하는 상황에 대해 알아보자 (이펙티브 자바 3) 10. equals는 일반 규약을 지켜 재정의하라 (1) equals 메서드는 재정의하기에 쉬워 보이지만 곳곳에 함정이 도사리고 있다. 우선적으로 equals 메서드를 재정의하지 않아도 될 경우를 살펴보고, 재정의가 필요하다면 어떤 규약을 지켜서 재정의� ckddn9496.tistory.com 반사성 (reflexivity) 반사성은 객체는 자기 자신과 같아야 한다는 규약이다. 이 규약을 위반하는 경우는 없을 것이다. 대칭성 (symmetry) 대칭성은 두 객체는 서로에 대한 동치 여부에 똑같이 답해야 한다는 규약이다. 부모 클래스 A와 A를 상속하는 B가 존재하고 각각 equals를 구현했다고 가정해보자. ..

equals 메서드는 재정의하기에 쉬워 보이지만 곳곳에 함정이 도사리고 있다. 우선적으로 equals 메서드를 재정의하지 않아도 될 경우를 살펴보고, 재정의가 필요하다면 어떤 규약을 지켜서 재정의해야 하는지 알아보자. equals 메서드를 재정의 할 필요가 없을 때 다음 열거한 상황 중 하나에 해당된다면 equals 메서드를 재정의하지 않는것이 좋다. 각 인스턴스가 본질적으로 고유하다. 값을 표현하는것이 나닌 동작하는 개채를 표현하는 클래스가 여기에 해당된다. 예시로 Thread와 같은 클래스가 여기 해당된다. Object의 equals 메서드는 이미 이러한 클래스에 딱 맞게 구현되어있다. 인스턴스의 논리적 동치성(logical equality)을 검사할 일이 없다. 인스턴스의 논리적인 동치성을 검사해야..

자바 라이브러리에는 close 메서드를 호출해 직접 닫아줘야 하는 자원이 많다. 자원 닫기는 클라이언트가 놓치기 쉬워서 예측할 수 없는 성능 문제로 이어지기 쉽다. 또한 안전망으로 사용하는 방법인 finalizer는 믿을만하지 못하다. try-finally 전통적으로 자원이 제대로 닫힘을 보장하는 수단으로 try-finally가 쓰였다. static String firstLineOfFile(String path) throws IOException { BufferedReader br = new BufferedReader(new FileReader(path)); try { return br.readLine(); } finally { br.close(); } } 하지만 위의 코드에는 문제점이 존재한다. 예외는..