<T>Story <T>Story

ITEM 11 equals를 재정의하려거든 hashCode도 재정의하라 equals를 재정의한 클래스 모두에서 hashCode도 재정의해야 한다 hashCode 일반 규약을 어기게 되어 해당 클래스의 인스턴스를 HashMap HashSet 같은 컬렉션의 원소로 사용할 때 문제가 발생 가능 재정의한 hashCode는 Object의 API문서에 기술된 일반 규약을 따라야 한다 서로 다른 인스턴스라면 되도록 해시코드도 서로 다르게 구현해야 한다 Object 명세에서 발췌한 규약 equals 비교에 사용되는 정보가 변경되지 않았다면, 애플리케이션이 실행되는 동안 그 객체의 hashCode 메서드는 몇 번을 호출해도 일관되게 항상 같은 값을 반환해야 한다 애플리케이션을 다시 실행한다면 이 값이 달라져도 상관없다 ..

import java.io.BufferedReader; import java.io.IOException; import java.io.InputStreamReader; public class Main { public static void main(String[] args) throws IOException { BufferedReader buf = new BufferedReader(new InputStreamReader(System.in)); StringBuilder sb = new StringBuilder(); int loopLeng = Integer.parseInt(buf.readLine()); for (int i = 0; i < loopLeng; i++) { String[] arr = buf.readL..

ITEM 10 equals는 일반 규약을 지켜 재정의하라 equals 메서드를 재정의 하지않는 경우 다음과 같은 경우에 equals 메서드를 재정의 하지 않는것이 최선이다 각 인스터스가 본질적으로 고유하다 값이 아니라 동작하는 개체를 표현하는 클래스 Thread 가 좋은 예시이다 인스턴스의 논리적 동치성을 검사할 필요가 없다 설계자의 의도에 따라 기본 equals 만으로 해결이 가능 어떠한 값을 검사 할때 꼭 같은 정규표현식을 쓸 필요는 없을수도 있다(논리적 동치성 검사가 필요 없을 수 있다는 것) 상위 클래스에서 재정의한 equals 메서드가 하위 클래스에도 딱 들어 맞는다 Set, List, Map 등의 구현체들은 상위 클래스에서 구현한 equals 메서드를 상속 받아 사용한다 AbstractSet ..

첫째 줄에 테스트 케이스의 개수 T가 주어진다. 각 테스트 케이스는 한 줄로 이루어져 있으며, 각 줄에 A와 B가 주어진다. (0 < A, B < 10) import java.io.BufferedReader; import java.io.IOException; import java.io.InputStreamReader; public class Main { public static void main(String[] args) throws IOException { BufferedReader buf = new BufferedReader(new InputStreamReader(System.in)); StringBuilder sb = new StringBuilder(); int loopLeng = Integer.p..

ITEM 9 try-finally보다는 try-with-resources를 사용하라 자원 닫기의 안전망으로 finalizer를 활용하는 경우가 많지만 item8에서 봤듯이 믿을만 하지 못하다 전통적으로 자원을 제대로 닫을때 사용하던 방법은 try-finally이다 예외가 발생하거나 메서드에서 반환되는 경우도 마찬가지static String firstLineOfFile(String path) throws IOException { BufferedReader br = new BufferedReader(new FileReader(path)); try { return br.readLine(); } finally { br.close(); } } 자원이 많아지면 지저분해진다static void copy(String ..

ITEM 8 finalizer와 cleaner사용을 피하라 finalizer는 기본적으로 쓰지 말아야 하며 java9에서는 사용자제 api로 지정했다 finalizer와 cleaner를 피하는 이유 즉시 실행된다는 보장이 없으며 실행 시점을 예측하기가 어렵다 상황에 따라 위험한 경우가 있어서 일반적으로는 불필요하다 정확한 시점에 실행되어야 하는 작업은 절대 할 수 없다 얼마나 빠르게 수행이 될지는 GC 알고리즘에 달려있고 GC 구현마다 천차만별이다 수행 시점 뿐 아니라 수행 여부도 보장하지 않는다 상태를 영구적으로 수정하는 작업에서는 절대 사용하지 말자 DB 영구 락 해제를 맡겼다가 분산 시스템 전체가 서서히 멈출수도 있다 동작 중 발생한 에러는 무시되며 처리할 작업이 남아 있어도 그 순간 종료된다 fi..

첫째 줄에 테스트 케이스의 개수 T가 주어진다. 각 테스트 케이스는 한 줄로 이루어져 있으며, 각 줄에 A와 B가 주어진다. A와 B는 콤마(,)로 구분되어 있다. (0 < A, B < 10) import java.io.BufferedReader; import java.io.IOException; import java.io.InputStreamReader; public class Main { public static void main(String[] args) throws IOException { BufferedReader buf = new BufferedReader(new InputStreamReader(System.in)); StringBuilder sb = new StringBuilder(); in..

입력은 여러 개의 테스트 케이스로 이루어져 있다. 각 테스트 케이스는 한 줄로 이루어져 있으며, 각 줄에 A와 B가 주어진다. (0 < A, B < 10) 입력의 마지막에는 0 두 개가 들어온다. import java.io.BufferedReader; import java.io.IOException; import java.io.InputStreamReader; public class Main { public static void main(String[] args) throws IOException { BufferedReader buf = new BufferedReader(new InputStreamReader(System.in)); StringBuilder sb = new StringBuilder(); ..

ITEM 7 다 쓴 객체 참조를 해제하라 GC에 너무 의존하지 말자 메모리 누수가 일어나는 상황 아래의 Stack을 구현한 간단한 예제로 메모리 누수가 발생하는 상황을 살펴보자 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..

종료 방식은 Ctrl + D 나 Ctrl + X로 종료하세요 import java.io.BufferedReader; import java.io.IOException; import java.io.InputStreamReader; public class Main { public static void main(String[] args) throws IOException { BufferedReader buf = new BufferedReader(new InputStreamReader(System.in)); StringBuilder sb = new StringBuilder(); String str = ""; while((str = buf.readLine()) != null) { String[] arr = str...