코딩하는 털보

이펙티브 자바, 아이템 11. equals를 재정의 하려거든 hashCode도 재정의하라 equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 한다. 그렇지 않으면 hashCode 일반 규약을 어기게 되어 HashMap 또는 HashSet 같은 컬렉션의 원소로 사용할 때 문제가 발생한다. hashCode 규약 equals 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 한다. equals가 두 객체를 같다고 판단했다면, 두 객체의 hashCode는 똑같은 값을 반환해야 한다. equals가 두 객체를 다르다고 판단했다면, 두 객체의 hashCode는 다르게 반환해야 해시 테이블의 ..

이펙티브 자바, 아이템 5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라 하나 이상의 자원에 의존하는 클래스가 있다. 예를들어 아래 SpellChecker 클래스는 dictionary에 의존한다. public class SpellChecker { private static final Lexicon dictionary = ...; public static boolean isValid(String word){ //... } } 예시에서는 인스턴스화를 막고 정적 유틸리티 클래스로 만들었는데, 이런 경우 dictionary를 단 하나만 사용한다고 가정해야 하기 때문에 여러가지 dictionary를 써야한다면 잘못된 방법이다. 싱글턴으로 만들어도 같은 문제가 생긴다. 그렇다면 자원의 final을 제거하고..

이펙티브 자바, 아이템 10. equals는 일반 규약을 지켜 재정의하라 equals 메서드는 다음 상황 중 하나에 해당하면 재정의하지 않는 것이 최선 각 인스턴스가 본질적으로 고유하다. ( 주로 값 클래스가 아닌 동작하는 개체를 표현하는 클래스 ex. Thread ) 인스턴스의 '논리적 동치성'을 검사할 일이 없다. 상위 클래스에서 재정의한 equals가 하위 클래스에서도 딱 들어맞는다. 클래스가 private이거나 package-private이고 equals 메서드를 호출 할 일이 없다. 그렇다면 equals를 재정의해야 할 때는 언제인가? 인스턴스간 논리적 동치성을 확인해야 하는데, 상위 클래스의 equals가 논리적 동치성을 비교하도록 재정의되지 않았을 때. (주로 값 클래스 ex...

이펙티브 자바, 아이템 9. try-finally 보다는 try-with-resources를 사용하라 try-finally try-finally는 두 개 이상의 자원을 사용할 때 코드가 지저분해진다. try 블록과 finally 블록 양쪽에서 예외가 발생할 수 있어서 문제를 진단하기 어렵게 할 수 있다. try-with-resources try-with-resources에서 자동으로 닫힐 자원은 AutoCloseable 인터페이스를 구현해야 한다. 가독성이 좋으며 문제를 진단하기도 좋다. try-finally 보다는 try-with-resources를 사용하라 예외는 없다. 가독성은 좋아지고 문제를 진단하기 유용해진다.

이펙티브 자바, 아이템 8. finalizer와 cleaner 사용을 피하라 자바의 두가지 객체 소멸자 finalizer, cleaner finalizer (자바9 deprecated) finalizer는 예측할 수 없고, 상황에 따라 위험할 수 있어서 일반적으로 불필요하다. 기본적으로 쓰지말아야 한다. cleaner cleaner는 finalizer보다는 덜 위험하지만, 여전히 예측할 수 없고, 느리고, 일반적으로 불필요하다. finalizer와 cleaner의 문제점 finalizer, cleaner가 예측할 수 없다는 것은, 객체에 접근할 수 없게 된 후 finalizer나 cleaner가 실행되기까지 얼마나 걸릴지 알 수 없다는 것. 즉, finalizer와 cleaner로는 제때 실행되어야 하는..

이펙티브 자바, 아이템 7. 다 쓴 객체 참조를 해제하라 자바의 가비지 컬렉터는 다 쓴 객체를 알아서 회수해가지만 그렇다고 메모리 관리에 더 이상 신경 쓰지 않아도 되는 것은 아니다. 가비지 컬렉션 언어에서는 메모리 누수를 찾기가 아주 까다롭다. 객체 참조 하나를 살려두면 가비지 컬렉터는 그 객체뿐아니라 그 객체가 참조하는 모든 객체를 회수해가지 못한다. 그래서 단 몇 개의 객체가 매우 많은 객체를 회수되지 못하게 할 수 있고 잠재적으로 성능에 악영향을 줄 수 있다. 해법은 참조해제. 해당 참조를 다 썼을 때 null 처리하면 된다. public Object pop() { if (size == 0) { throw new EmptyStackException(); } Object result = elemen..

이펙티브 자바, 아이템 6. 불필요한 객체 생성을 피하라 똑같은 기능의 객체를 매번 생성하기보다는 객체 하나를 재사용하는 편이 나을 때가 많다. String String s = new String("bikini"); 대신 String s = "bikini" 전자는 매번 새로운 인스턴스를 만들지만 후자는 하나의 인스턴스를 사용하며 같은 문자열 리터럴을 사용하는 코드에서 같은 객체를 재사용한다. 정적 팩터리 메서드를 제공하는 불변 클래스 Boolean(String) 생성자 대신 Boolean.valueOf(String) 생성 비용이 비싼 객체 가능하다면 비싼 객체를 반복적으로 생성하지말고 정적 초기화 과정에서 직접 캐싱해두자. 예를들면 String.matches() 메서드는 내부에서 Pattern 인스턴스를..

이펙티브 자바, 아이템 4. 인스턴스화를 막으려거든 private 생성자를 사용하라 정적 멤버만 담은 유틸리티 클래스는 인스턴스로 만들어 쓰려고 설계한 게 아니다. 그러나 생성자를 명시하지 않으면 컴파일러가 자동으로 기본 생성자를 만들어 주기 때문에 private 생성자를 추가하여 클래스의 인스턴스화를 막을 수 있다. 명시적인 생성자를 추가하면 기본 생성자가 자동으로 만들어지지 않으며, 명시적인 생성자가 private이므로 클래스 바깥에서는 접근할 수 없다. 코드에 인스턴스화 방지용이라는 주석을 추가하는 것도 좋다. 생성자가 private 생성자 하나만 있는 경우에는 하위 클래스의 생성자에서 사용될 상위클래스 생성자가 없는 것이므로 상속도 막을 수 있다.

이펙티브 자바, 아이템 3. private 생성자나 열거 타입으로 싱글턴임을 보증하라 싱글턴 : 인스턴스를 오직 하나만 생성할 수 있는 클래스 public static final 인스턴스 public class Printer { private final String name = "yoyo printer"; private final String owner = "tuna"; public static final Printer INSTANCE = new Printer(); private Printer() { } public void print(String in) { System.out.println("========================="); System.out.println("this is "+thi..

이펙티브 자바, 아이템 2. 생성자에 매개변수가 많다면 빌더를 고려하라. 생성자든 정적 팩토리 메서드든 매개변수가 많다면 적절하게 대응하기 쉽지 않다. 생성자에 매개변수가 많을 때 사용하는 방법들을 알아보았다. 점층적 생성자 패턴 필수적 매개변수만 받는 생성자부터 시작해서 선택적 매개변수 한 개씩을 늘려가면서 모든 매개변수를 받는 생성자까지 늘려가는 단순한 방식이다. public class Book { private String title; private String author; private int price; private String publisher; private String description; private String subTitle; public Book(String title, St..