<T>Story <T>Story

보호되어 있는 글입니다.

ITEM 12 toString을 항상 재정의하라 Object의 기본 toString 메서드는 우리가 작성한 클래스에 적합한 문자열을 반환하는 경우는 거의 없다 단순히 클래스_이름@16진수로_표시한_해시코드를 반환한다 toString의 일반 규약 간결하면서 사람이 읽기 쉬운 형태의 유익한 정보를 반환해야 한다 모든 하위 클래스에서 이 메서드를 재정의하라 toString 메서드를 잘 구현한 클래스는 디버깅이 용이하다 toString 메서드가 호출되는 경우 객체를 println, printf, 문자열 연결 연산자(+), assert 구문에 넘길때 디버거가 객체를 출력할때 즉 직접 호출하지 않아도 어딘가는 쓰인다 toString 메서드는 해당 객체의 주요 정보를 모두 반환하는게 좋다 map 객체를 출력한다고 가..

ITEM 11 equals를 재정의하려거든 hashCode도 재정의하라 equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 한다 hashCode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashMap HashSet 같은 컬렉션의 원소로 사용할 때 문제가 발생 가능 재정의한 hashCode는 Object의 API문서에 기술된 일반 규약을 따라야 한다 서로 다른 인스턴스라면 되도록 해시코드도 서로 다르게 구현해야 한다 Object 명세에서 발췌한 규약 equals 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 한다 애플리케이션을 다시 실행한다면 이 값이 달라져도 상관없다 ..

ITEM 10 equals는 일반 규약을 지켜 재정의하라 equals 메서드를 재정의 하지않는 경우 다음과 같은 경우에 equals 메서드를 재정의 하지 않는것이 최선이다 각 인스터스가 본질적으로 고유하다 값이 아니라 동작하는 개체를 표현하는 클래스 Thread 가 좋은 예시이다 인스턴스의 논리적 동치성을 검사할 필요가 없다 설계자의 의도에 따라 기본 equals 만으로 해결이 가능 어떠한 값을 검사 할때 꼭 같은 정규표현식을 쓸 필요는 없을수도 있다(논리적 동치성 검사가 필요 없을 수 있다는 것) 상위 클래스에서 재정의한 equals 메서드가 하위 클래스에도 딱 들어 맞는다 Set, List, Map 등의 구현체들은 상위 클래스에서 구현한 equals 메서드를 상속 받아 사용한다 AbstractSet ..

ITEM 9 try-finally보다는 try-with-resources를 사용하라 자원 닫기의 안전망으로 finalizer를 활용하는 경우가 많지만 item8에서 봤듯이 믿을만 하지 못하다 전통적으로 자원을 제대로 닫을때 사용하던 방법은 try-finally이다 예외가 발생하거나 메서드에서 반환되는 경우도 마찬가지static String firstLineOfFile(String path) throws IOException { BufferedReader br = new BufferedReader(new FileReader(path)); try { return br.readLine(); } finally { br.close(); } } 자원이 많아지면 지저분해진다static void copy(String ..

ITEM 8 finalizer와 cleaner사용을 피하라 finalizer는 기본적으로 쓰지 말아야 하며 java9에서는 사용자제 api로 지정했다 finalizer와 cleaner를 피하는 이유 즉시 실행된다는 보장이 없으며 실행 시점을 예측하기가 어렵다 상황에 따라 위험한 경우가 있어서 일반적으로는 불필요하다 정확한 시점에 실행되어야 하는 작업은 절대 할 수 없다 얼마나 빠르게 수행이 될지는 GC 알고리즘에 달려있고 GC 구현마다 천차만별이다 수행 시점 뿐 아니라 수행 여부도 보장하지 않는다 상태를 영구적으로 수정하는 작업에서는 절대 사용하지 말자 DB 영구 락 해제를 맡겼다가 분산 시스템 전체가 서서히 멈출수도 있다 동작 중 발생한 에러는 무시되며 처리할 작업이 남아 있어도 그 순간 종료된다 fi..

ITEM 7 다 쓴 객체 참조를 해제하라 GC에 너무 의존하지 말자 메모리 누수가 일어나는 상황 아래의 Stack을 구현한 간단한 예제로 메모리 누수가 발생하는 상황을 살펴보자 public class Stack { private Object[] elements; private int size = 0; private static final int DEFAULT_INITIAL_CAPACITY= 16; public Stack() { elements = new Object[DEFAULT_INITIAL_CAPACITY]; } public void push(Object e) { ensureCapacity(); elements[size++] = e; } public Object pop() { if (size == 0..

ITEM 6 불필요한 객체 생성을 피하라 같은 기능의 객체라면 매번 생성 하는것 보다는 객체를 재사용 하자 객체 재사용은 성능상 이점을 가져다준다 안좋은예시 String str = new String("hello"); 위와 같은 코드는 실행시 매번 hello 라는 값을 가진 인스턴스를 새로 만들게 된다 인자로 들어가는 hello는 이미 만들려고 하는것 그 자체이다 전혀 쓸데 없는 행위이다 개수가 많아진다면 그만큼 쓸데없는 String 인스턴스가 생길것이다 좋은예시 String str = "hello"; 위의 코드는 첫번째 예시와 같은 결과를 도출한다 위의 코드는 인스턴스를 한번만 생성하고 재사용 하기 때문에 불필요한 인스턴스에 생성을 방지한다 또한 위의 코드는 같은 가상머신 내에서 이러한 문자열 리터럴을..