반갑습니다!

Java는 두 가지 객체 소멸자를 제공 그 중 finalizer 는 예측할 수 없고, 상황에 따라 위험할 수 있어서 일반적으로 불필요함 오동작, 낮은 성능, 이식성 문제의 원인이 되기도 함 Java 9에서는 finalizer 를 deprecated하고 cleaner 를 대안으로 소개함 cleaner 는 덜 위험하지만, 여전히 예측할 수 없고, 느리고, 일반적으로 불필요함 주의 Java의 finalizer 와 cleaner 는 C++의 파괴자(destructor)와는 다른 개념 C++에서 파괴자는 특정 객체와 관련된 자원을 회수하는 보편적인 방법 Java에서는 접근할 수 없게 된 객체를 가비지 컬렉터가 알아서 회수함 C++의 파괴자는 비메모리 자원을 회수하는 용도로 사용 Java에서는 try-with-re..

Java처럼 가비지 컬렉터를 갖춘 언어를 사용하다보면 자칫 메모리 관리에 신경 쓰지 않아도 된다고 오해할 수 있음 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) throw new EmptyStackException();..

똑같은 기능의 객체를 매번 생성하기보다는 객체 하나를 재사용하는 편이 나을 때가 많음 재사용은 빠르고 세련됨 특히 불변 객체는 언제든 재사용할 수 있음 극단적인 예시 String s = new String("bikini"); // 따라 하지 말 것! 실행될 때마다 String 인스턴스를 새로 만듬 반복문이나 빈번히 호출되는 메서드 안에 있다면 쓸데없는 String 인스턴스가 수백만 개 만들어질 수 있음 개선 String s = "bikini"; 새로운 인스턴스를 매번 만드는 대신 하나의 String 인스턴스를 사용함 같은 가상 머신 안에서 이와 똑같은 문자열 리터럴을 사용하는 모든 코드가 같은 객체를 재사용함이 보장됨 정적 팩터리 메서드 생성자 대신 정적 팩터리 메서드(아이템 1)를 제공하는 불변 클래스..

아이템 5: 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라 많은 클래스가 하나 이상의 자원에 의존함 ex) 맞춤법 검사기는 사전(dictionary)에 의존함 이런 클래스를 정적 유틸리티 클래스로 구현하는 모습을 드물지 않게 볼 수 있음 정적 유틸리티를 잘못 사용한 예 - 유연하지 않고 테스트하기 어렵다 public class SpellChecker { private static final Lexicon dictionary = ...; private SpellChecker() {} // 객체 생성 방지 public static boolean isValid(String word) { ... } public static List suggestions(String typo) { ... } } 싱글턴을 ..

단순히 정적 메서드와 정적 필드만을 담은 클래스가 필요할 때가 있다 ex) java.lang.Math, java.util.Arrays 기본 타입 값, 배열 관련 메서드들이 모여있음 ex) java.util.Collections 특정 인터페이스를 구현하는 객체를 생성해주는 정적 메서드(혹은 팩터리)를 모아놓을 수 있음 final 클래스와 관련한 메서드들을 모아놓을 수 있음 final 클래스는 상속이 불가능하므로 하위 클래스에 메서드를 넣는 건 불가능 인스턴스화를 막는 방법 정적 멤버만 담은 유틸리티 클래스는 인스턴스로 만들어 사용하려고 설계된 것이 아니다 생성자를 명시해주지 않으면 컴파일러가 자동으로 생성자를 만들어주므로 의도치 않게 인스턴스화 가능할 수 있음 유틸리티 클래스를 추상 클래스로 만드는 것으로..