Effective Java

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 11. equals를 재정의하려거든 hashCode도 재정의하라 equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 한다. 만약 그렇지 않으면 hashCode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashMap이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제를 야기함 * Object 명세에서 발췌한 규약 equals 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 한다. 단, 애플리케이션을 다시 실행 시 이 값이 달라져도 상관없다. equals(Object)가 ..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 10. equals는 일반 규약을 지켜 재정의하라 equals 메서드는 재정의하기 쉬워 보이지만 주의할 필요가 있다. equals 메서드를 재정의하지 않는 다면 그 클래스의 인스턴스는 오직 자기 자신과만 같게 된다. 1. equals메서드를 재정의하지 않아도 되는 경우 1) 각 인스턴스가 본질적으로 고유한 경우 : 값을 표현하는 게 아니라 동작하는 개체를 표현하는 클래스가 해당. ex) Thread 2) 인스턴스의 '논리적 동치성'을 검사할 일이 없는 경우 : java.util.regex.Pattern은 equals를 재정의해서 두 Pattern의 인스턴스가 같은 정규표현식을 나타내는 지를 검사하는 방법도..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 9. try-finally보다는 try-with-resources를 사용하라 자바 라이브러리에는 close메서드를 호출해 직접 닫아줘야 하는 자원이 있다. ex) InputStream, OutputStream, java.sql.Connection 직접 닫아주는 방법은 아래와 같다. (finalizer는 믿을만하지 않기 때문에 언급하지 않음. 이전 포스팅 참고) 1. try-finally 자원이 하나인 코드에서의 try-finally 코드는 나쁘지 않지만 자원이 두 개 이상부터는 지저분해지기 시작한다. 또한, 두 번째 예외가 첫 번째 예외를 집어삼킬 가능성이 있다. → 스택 추적 내역에 첫 번째 예외의 정보..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 8. finalizer와 cleaner 사용을 피하라 자바는 finalizer와 cleaner라는 두 가지 객체 소멸자를 제공한다. 이 두 가지 객체 소멸자 모두 일반적으로 불필요하다. - finalizer : 예측할 수 없고, 상황에 따라 위험할 수 있다. - cleaner : finalizer보다는 덜 위험하지만 여전히 예측할 수 없고 느리다. 1. finalizer와 clenaer의 단점 1. finalizer와 cleaner는 즉시 수행된다는 보장이 없기 때문에 제때 실행되어야 하는 작업은 절대 할 수 없다. ex) 파일 닫기를 finalizer, cleaner에 맡기면 중대한 오류를 일으킬 수 있..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 7. 다 쓴 객체 참조를 해제하라 C/C++ 과는 다르게 Java는 GC(Garbage Collector)를 갖추고 있기 때문에 다 쓴 객체를 알아서 회수한다. 하지만, GC가 있다고 해서 메모리 관리에 신경쓰지 않아도 되는 것은 아니다. 1. Stack 스택을 간단히 구현하면 아래와 같다. 1) 메모리 누수가 발생하는 코드 기능적으로는 전혀 문제가 없음 메모리 누수가 발생함 스택이 커졌다가 줄어들었을 때, 스택에서 꺼내진 객체들을 GC가 회수하지 않음 스택에서 꺼내진 객체들은 스택에서 여전히 해당 객체들을 바라보고 있기 때문 (이를 '다 쓴 참조(obsolete reference)' 라고 함) 다 쓴 참..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 6. 불필요한 객체 생성을 피하라 - 똑같은 기능의 객체를 매번 생성하기보다는 객체 하나를 재사용하는 편이 빠르고 세련된 경우가 많다. - 불변 객체(String)는 언제든 재사용할 수 있다. (불변 객체라면 재사용해도 안전함이 명백함) - 생성자 대신 정적 팩터리 메서드를 제공하는 불변 클래스에서는 정적 팩터리 메서드를 사용해 불필요한 객체 생성 피할 수 있다. → Boolean(String) 생성자 대신, Boolean.valueOf(String) 팩터리 메서드를 사용하는 것이 좋음(생성자는 새로운 객체를 만들기 때문) 1. String 1) String 선언의 나쁜 예 실행될 때마다 새로운 Strin..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라 클래스에서 하나 이상의 자원에 의존을 할 때, 이를 구현하는 방법 중 잘못된 예가 있다. SpellChecker 라는 클래스가 사전에 의존한다고 가정해보자. 1) 정적 유틸리티를 잘못 사용 public class SpellChecker { private static final Lexicon dictionary = ...;// 의존 대상(사전) private SpellChecker() { }// private 생성자를 정의함으로써 객체 생성 방지 ... } 2) 싱글톤을 잘못 사용 public class SpellChecker { private fi..

이 포스팅에서 작성하는 내용은 EFFECTIVE JAVA(이펙티브자바) 에서 발췌하였습니다. 아이템 4. 인스턴스화를 막으려거든 private 생성자를 사용하라 단순히 정적 메서드와 정적 필드만을 담은 클래스를 만들 때가 있다. 예를 들어 java.lang.Math 와 java.util.Arrays처럼 기본 타입 값이나 배열 관련 메서드들을 모아둘 수 있다. 또, final 클래스와 관련한 메서드들을 모아놓을 때도 사용한다. 이러한 정적 멤버만 담은 유틸리티 클래스는 인스턴스로 만들어 쓰려고 설계한 것은 아니기에 인스턴스화를 막아야 할 필요가 있다. 클래스를 정의할 때 생성자를 따로 명시해주지 않으면 컴파일러가 자동으로 기본 생성자를 생성한다. 이 때 자동으로 생성되는 기본 생성자는 매개변수를 받지 않는..