개발 성장 일기 :)

아이템36. 비트 필드 대신 EnumSet을 사용하라 서로 다른 2의 거듭제곱 값을 할당한 정수 열거 패턴이다. 아래와 같은 식으로 비트별 OR을 사용해 여러 상수를 하나의 집합으로 모을 수 있으며, 이런 집합을 삐트 필드라 한다. public class Text{ public static final int STYLE_BOLD = 1

아이템35. ordinal 메서드 대신 인스턴스 필드를 사용하라 열거 타입 상수는 열거 타입에서 몇 번째 위치인지를 반환하는 ordinal 메서드를 제공한다. 다만, 상수 선언의 순서가 바뀌거나 값의 중간이 없는 경우 ordinal을 쓰는 것은 좋지 않다. 해결책으로 열거 타입 상수에 연결된 값은 ordinal 메서드 대신, 인스턴스 필드에 저장하자. // ordinal을 잘못 사용한 예 - 따라하지 말 것 public enum Ensemble{ SOlO, DUET, TRIO, OCTET, NONET; public int numberOfMusicians() { return ordinal() + 1; } } public enum Ensemble{ SOlO(1), DUET(2), TRIO(3), OCTET(..

아이템34. int 상수 대신 열거 타입을 사용하라 열거 타입은 일정 개수의 상수 값을 정의한 다음, 그 외의 값은 허용하지 않는 타입이다. 열거타입 정리 참조 1. 정수 열거 패턴 기법 public static final int APPLE_FUJI = 0; public static final int APPLE_PIPPIN = 1; public static final int APPLE_GRANNY_SMITH = 2; public static final int ORANGE_NAVEL =0; public static final int ORANGE_TEMPLE =1; public static final int ORANGE_BLLOD = 2; 단점 타입 안전을 보장할 방법이 없으며 표현력이 좋지 않다. if(A..

아이템12. toString을 항상 재정의하라 toString의 규약은 "모든 하위 클래스에서 이 메서드를 재정의하라"고 한다. toString을 잘 구현한 클래스는 사용하기에 훨씬 즐겁고, 그 클래스를 사용한 시스템은 디버깅하기 쉽다. 포맷을 명시하던 의도를 명확히 밝혀야 한다. 또한 toString이 반환한 값에 포함된 정보를 얻어오로 수 있는 API를 제공하자. 정적 유틸리티 클래스(인스턴스를 만들 수 없는 유틸리티 클래스-아이템4) 는 toString을 제공할 이유가 없다. 대부분의 열거타입도 이미 자바가 완벽한 toString을 제공하므로 재정의하지 않아도 된다. 정리 모든 구체 클래스에서 Object의 toString을 재정의하자. 상위클래스에서 이미 알맞게 재정의한 경우는 예외. toStri..

아이템11. equals를 재정의하려거든 hashCode도 재정의하라 equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 한다. Object 명세서 규약 equals 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 hashCode메서드는 몇번을 호출해도 일관된 값을 반환해야한다. equals(Object)가 두 객체를 같다고 판단했다면, hashCode도 똑같은 값을 반환해야 한다. equals(Object)가 두 객체를 다르다고 판단했더라도, 두 객체의 hashCode가 서로 다른 값을 반환할 필요는 없다. 명세서 규약 2번째를 보면 논리적으로 같은 객체는 같은 해시코드를 반환해야 하기 때문에, equals재정의했다면 hashCode도 재정의해야 한다! hashC..

아이템10. equals는 일반 규약을 지켜 재정의하라 1. 각 인스턴스가 본질적으로 고유하다. 값을 표현하는 게 아니라 동작하는 개체를 표현하는 클래스의 경우. ex. Thread - Object의 equals는 메서드는 이러한 클래스에 딱 맞게 구현되었다. 2. 인스턴스의 '논리적 동치성(logical equality)'을 검사할 일이 없다. java.util.regex.Pattern은 equals를 재정의해서 두 Pattern의 인스턴스가 같은 정규표현식을 나타내는지 검사하는 논리적 동치성을 검사하는 방법도 있다. 하지만 설계자가 논리적 동치성을 검사할 필요가 없다고 판단했다면 Object의 기본 equals만으로 해결된다. 3. 상위 클래스에서 재정의한 equals가 하위 클래스에도 딱 들어맞는다..

아이템9. try-finally보다는 try-with-resources를 사용하라 자원이 제대로 닫힘을 보장하는 수단으로 try-finally 가 많이 쓰였다. try-finally 보다 try-with-resouces를 사용하자. (예외는 없다!) 훨씬 간결하고 문제 진단하기가 쉽다. try-finally 를 이용한 자원회수 방법 // try-finally를 이용한 자원회수 방법 - 하지만 최선의 방책이 아니다! static String firstLineOfFile(String path) throws IOException{ BufferdReader br= new BufferedReader( new FileReader(path)); try{ return br.readLine(); } finally{ br..

아이템8. finalizer와 cleaner 사용을 피하라 자바는 두 가지 객체 소멸자 제공을 제공한다 : finalizer / cleaner finalizer 예측할 수 없고, 상황에 따라 위험할 수 있어 일반적으로 불필요하다. 기본적으로 '쓰지 말아야'하며, 자바9에서는 finalizer을 사용자제 API로 지정했다. cleaner finalizer보다는 덜 위험하지만, 여전히 예측할 수 없고, 느리고 일반적으로 불필요하다. 사용을 피해야 하는 이유 1. finalizer 와 cleaner은 즉시 수행된다는 보장이 없다. 둘다 제때 실행되어야 하는 작업은 절대 할 수 없다. 2. 수행 시점뿐 아니라 수행 여부조차 보장하지 않는다. 상태를 영구적으로 수정하는 작업에서는 절대 finalizer나 clea..

아이템7. 다 쓴 객체 참조를 해제하라 자바의 가비지 컬렉터를 통해 메모리 관리에 신경쓰지 않아도 된다고 오해할 수 있지만, 절대 아니다. 가비지 컬렉션 언어에서는 메모리 누수를 찾기가 아주 까다롭다. 객체 참조 하나를 살려두면 가비지 컬렉터는 그 객체뿐 아니라 그 객체가 참조하는 모든객체(그리고 또 그 객체들이 참조하는 모든객체..)를 회수해가지 못한다. 해법은 해당 참조를 다 썼을때 null 처리(참조해제)하면 된다. null를 하면 null처리한 참조를 실수로 사용하려하면 NullPointerException을 던져 오류를 알 수 있다. 참조해제하는 가장 좋은 방법은 그 참조를 담은 변수를 유효범위(scope) 밖으로 밀어내는 것이다. 모든 객체를 다 쓰지마자 null처리로 모두 바꾸는 일은 프로그..

아이템6. 불필요한 객체 생성을 피하라. 똑같은 기능의 객체를 매번 생성하기보다는 객체 하나를 재사용하는 편이 나을 때가 많다. 재사용은 빠르고 세련되다, 특히 불변객체는 언제든 재사용할 수 있다. // 하지 말아야 할 코드! // 실행될 때마다 String 인스턴스를 새로 만든다. 완전 쓸데없는 행위! String s= new String("biki"); //개선된 버전 // 같은 가상머신 안에서 똑같은 문자열 리터럴을 사용하는 모든 코드가 같은 객체를 재사용함이 보장된다. String s= "biki" 생성자 대신 정적 팩터리 메서드(아이템 1)를 제공하는 불변 클래스에서는 정적 팩터리 메서드를 사용해 불필요한 객체 생성을 피할 수 있다. Boolean(String) 생성자 보다는 Boolean.va..