climb-up-the-stairs climb-up-the-stairs

equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 한다. 클래스의 인스턴스를 HashMap이나 HashSet 같은 컬렉션의 원소로 사용할 때 문제를 일으킬 것이다. [object 명세 규약] 1. equals 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 한다. 애플리케이션 다시 실행했을 시 이 값이 달라져도 된다. 2. equals가 두 객체를 같다고 판단했다면, 두 객체의 hashCode는 똑같은 값을 반환해야 한다. 3. equals가 두 객체를 다르다고 판단했더라도, 두 객체의 hashCode가 서로 다른 값을 반환할 필요 없다. 다른 객체에 대해서는 다른 값을 반환해..

[재정의 하지 않는 것이 좋은 예]1. 각 인스턴스가 본질적으로 고유하다. - 동작하는 개체를 표현하는 클래스(Thread) 2. 인스턴스의 논리적 동치성(logical equality)을 검사할 일이 없다. 3. 상위 클래스에서 재정의한 equals가 하위 클래스에도 딱 들어맞는다. -대부분의 Set 구현체는 AbstractSet이 구현한 equals를 상속받아 쓰고, List 구현체들은 AbstractList로부터, Map 구현체들은 AbstractMap으로부터 상속받아 그대로 쓴다. 4. 클래스가 private이거나 package-private이고 equals 메서드를 호출할 일이 없다. 실수로 호출되는 걸 막는 코드이다. Override public boolean equals (Object o) ..

InputStream, OutputStream, java.sql.Connection 등 close 메서드를 호출해 직접 닫아줘야하는 자원들이 많다. [try-finally는 자원을 회수하는 최선의 방책이 아니다.]static String firstLineOfFile(String path) throws IOException { BufferedReader br = new BufferedReader(new FileReader(path)); try { return br.readLine(); } finally { br.close(); } } [자원이 둘 이상이면 try-finally 방식은 지저분하다.]static void copy(String src, String dst) throws IOException { ..

자바는 두 가지 객체 소멸자를 제공한다.1. finalizerfinalizer는 예측할 수 없고, 상황에 따라 위험할 수 있어 일반적으로 불필요하다. => 오동작, 낮은 성능, 이식성 문제의 원인 2. cleanercleaner는 finalizer 대안으로 위험은 덜하지만, 예측 불가능하고, 일반적으로 불필요하다. finalizer와 cleaner로는 제때 실행되야 하는 작업은 절대 할 수 없다. 느린 finalizer 처리는 현업에서도 실제로 문제를 일으킨다. finalizer 스레드는 우선순위가 낮아서 실행될 기회를 제대로 얻지 못한다. 하지만 cleaner는 자신을 수행할 스레드를 제어할 수 있다는 면에서 조금 낫다 => 백그라운드에서 수행되며 가비지 컬렉터의 통제하에 있으니 즉각 수행되리란 보장은..

자바는 가비지 컬렉터를 갖췄기 때문에 다 쓴 객체는 알아서 회수해 간다. [메모리 누수가 일어나는 예제]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(); return..

똑같은 기능의 객체는 매번 생성하기보더 객체 하나를 재사용하는 게 좋다. [잘못된 예제]String s = new String("cream");실행될 때마다 String 인스턴스를 새로 만든다. 만약 반복문이나 자주 호출되는 메서드 안에 있다면 쓸데없는 String 인스턴스가 수없이 많이 만들어질 수 있다. [개선된 예제]String s = “cream";새로운 인스턴스 대신 하나의 String 인스턴스를 사용한다. 같은 가상 머신 안에서 똑같은 문자열 리터럴을 사용하는 모든 코드가 같은 객체를 재사용함이 보장된다. 생성자 대신 정적 팩터리 메서드를 제공하는 불변 클래스에선 정적 팩터리 메서드를 사용해 => 불필요한 객체 생선늘 피할 수 있다. Boolean(String) 생성자 대신 Boolean.va..

많은 클래스가 하나 이상의 자원에 의존한다. [정적 유틸리티 잘못된 예제]public class SpellChecker { private static final Lexicon dictionary = ...; private SpellChecker() {} //객체 생성 방지 public static boolean isValid(String word) {...} public static List suggestions(String typo) {...} }[싱글톤 잘못된 예제]public class SpellChecker { private final Lexicon dictionary = ...; private SpellChecker(...){} public static SpellChecker INSTANCE =..

[인스턴스화(객체화)를 막으려면 private 생성자를 사용하라]정적 메서드와 정적 필드만 담은 클래스를 만들고싶을 때(객체지향적으로 사고하지않는 방식) java.lang.Math와 java.util.Arrays처럼 기본 타입 값이나 배열 관련 메서드들을 모아놓을 수 있다. java.util.Collections처럼 특정 인터페이스를 구현하는 객체를 생성해주는 정적 메서드를 모아놓을 수 있다. 그리고 final클래스와 관련한 메서드를 모아놓을 때 사용한다. => final class로 선언되면 상속받을 수 없기 때문에 내부의 모든 method는 overridding(재정의)될 수 없다. 유틸리티 클래스(인스턴스 메서드, 인스턴스 변수를 제공하지 않고 정적 메서드와 변수만 제공하는 클래스이다. 비슷한 기능..