선 조치 후 분석

clone() 메서드는 객체의 모든 필드를 복사하여 새로운 객체에 넣어 반환하는 동작을 수행한다. 즉, 필드의 값이 같은 객체를 새로 만드는 것이다. Clonable의 역할 - 복제해도 되는 클래스임을 나타내는 믹스인 인터페이스 - Object 클래스에 protected clone()이라는 메서드가 있다. - Clonable 인터페이스는 clone() 메서드의 동작방식을 결정한다. - Clonable을 구현하지 않은 인스턴스에서 clone()을 호출하면 CloneNotSupportedException을 던진다. 믹스인( Mixed in ) 인터페이스 객체지향언어에서 다른 클래스에서 '사용'할 목적으로 만들어진 클래스 - '포함(has-a)'으로 설명된다. '상속(is-a)'과 비교되는 개념. Compos..

toString()은 Object 클래스의 public 메서드이다. 기본적으로 toString()은 "클래스의 이름@hashCode(16진수 변환)" 값을 반환한다. 기본적으로 이 값은 사람이 읽기 어려울 뿐 아니라 쓸모없는 메시지로 남게 된다. 가급적이면 그 객체가 가진 주요 정보 모두를 반환하는 게 좋다. 객체가 크거나 문자열로 표현하기에 적합하지 않다면 요약정보로 표현해도 된다. toString을 구현할 때 반환값의 포맷 문서화에 따른 장단점 장점 - 포맷을 명시하면, 그 객체는 표준적이고, 명확하고, 사람이 읽을 수 있게 된다. 단점 - 포맷을 명시하면, 평생 그 포맷에 얽매이게 된다. 프로그래머들이 그 포맷에 맞춰 파싱이 필요하다. 반대로 포맷을 명시하지 않는다면, 향후 릴리스에서 정보를 더 넣..

자바의 최고 조상 Object는 equals 메서드뿐만 아니라 hashCode 메서드도 기본적으로 정의되어 있다. HashMap, HashSet과 같은 Collection에서 Object의 hashCode 메서드를 활용하기 때문이다. 그래서 Item10에서 Object를 재정의했다면, hashCode도 함께 재정의해야 한다. Object 명세서에서 정의되어 있는 hashCode가 지켜야 하는 규약이다. equals 비교에 사용되는 정보가 변경되지 않았다면, hashCode는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 한다. equals가 두 객체를 같다고 판단했다면, 두 객체의 hashCode는 동일한 값을 반환해야 한다. equals가 두 객체를 다르다고 판단했더라도, 두 객체의 hashCod..

결론부터 말하면 이렇다. 꼭 필요한 경우가 아니라면, equals를 재정의하지 말자. 재정의해야 하는 경우라면 클래스의 핵심 필드 모두가 5가지 규약을 지켜가며 비교하자. equals 메서드는 재정의하기 쉬워 보이지만, 곳곳에 함정이 도사리고 있어서 자칫하면 끔찍한 결과를 초래할 수 있다. 문제를 회피하기 가장 좋은 방법은 재정의를 하지 않는 것이다. 그냥 두면 그 클래스의 인스턴스는 오직 자기 자신과만 같게 된다. 그러니 다음에서 열거한 상황 중 하나에 해당한다면 재정의하지 않는 것이 최선이다. 1. 각 인스턴스가 본질적으로 고유하다. 값을 표현하는 게 아니라 동작하는 개체를 표현하는 클래스가 여기에 해당한다. Thread가 좋은 예로 Object의 equals 메서드는 이러한 클래스에 딱 맞게 구현되..

자바 라이브러리에는 close 메서드를 호출해 직접 닫아줘 하는 자원이 있다. 예를 들어, InputStream, OutputStream, java.sql.Connection 등 자원 닫기는 클라이언트가 놓치기 쉬워서 예측할 수 없는 성능 문제를 야기할 수 있다. 전통적으로 자원이 제대로 닫힘을 보장하는 수단으로 try-finally 가 사용되었다. 아래 코드처럼 close를 호출하게 되면 문제가 발생하지 않는다. BufferedReader는 사용 중 IOException이 발생할 수 있는데, 만약 br.readLine() 메서드에서 Exception이 발생하게 되면 메서드는 종료되고 close는 호출되지 않고 스트림이 메모리에 남아있게 된다. public String inputString() throw..

자바에서 객체소멸은 GC (Gabage Collector)가 담당하고, 비 메모리 자원회수는 try-with-resources, try-finally로 해결한다. 자바에서 제공하는 2가지 객체 소멸자, finalizer와 cleaner는 기본적으로 사용하지 말아야 한다. 사용하면 안 되는 이유 finalizer : 예측할 수 없고, 위험하며, 느리고, 일반적으로 불필요하다. cleaner : finalizer보다는 덜 위험하지만 여전히 예측할 수 없고, 느리며, 보통은 불필요하다. 단점 1 - 즉시 수행된다는 보장이 없다 finalizer와 cleaner는 호출된 후 언제 실행될지 알 수 없다. 즉, 제때 실행되어야 하는 작업을 절대 할 수 없다. finalizer와 cleaner의 수행 속도는 가비지 ..