1장 들어가기

이 책에서 컴포넌트란, 개별 메서드부터 여러 패키지로 이뤄진 복잡한 프레임워크까지 재사용 가능한 모든 소프트웨어 요소를 뜻한다.

컴포넌트는 가능한 한 작되, 그렇다고 너무 작아서는 안 된다.
-> 정해진 동작이나 예측할 수 있는 동작만 수행해야 한다. (명료성과 단순성)

코드는 복사되는 게 아니라 재사용되어야 한다.
컴포넌트 사이의 의존성은 최소로 유지해야 한다.
오류는 만들어지자마자 가능한 한 빨리(되도록 컴파일타임에) 잡아야 한다.

자바가 지원하는 타입(type, 자료형) :
인터페이스, 클래스, 배열, 기본 타입

애너테이션 annotation (인터페이스의 일종)

열거타입 enum (클래스의 일종)

인터페이스, 클래스, 배열 -> 참조 타입 (reference type)
즉, 클래스의 인스턴스와 배열은 객체(object)인 반면, 기본 타입은 그렇지 않다.

클래스의 멤버 :
필드, 메서드, 멤버 클래스, 멤버 인터페이스

메서드 시그니처
: 메서드 이름, 입력 매개변수(parameter) 타입
(반환값의 타입은 시그니처에 포함되지 않는다.)

인터페이스 상속 대신
"클래스가 인터페이스를 구현한다.(implement)" 혹은
"인터페이스가 다른 인터페이스를 확장한다.(extend)" 라고 표현

아무것도 명시하지 않은 접근 수준(access level)을 이야기 할 때는
(기술적으로 정확한 이름인) 패키지 접근(package access) 대신
"패키지-프라이빗(package-private)"을 쓴다.

공개 API(exported API),줄여서 API(Application Programming Interface)는
프로그래머가 클래스, 인터페이스, 패키지를 통해 접근할 수 있는 모든 클래스, 인터페이스, 생성자, 멤버, 직렬화된 형태(serialized form)

API를 사용하는 프로그램 작성자(사람) -> API의 사용자(user)
API를 사용하는 클래스(코드) -> 그 API의 클라이언트(client)

API 요소 :
클래스, 인터페이스, 생성자, 멤버, 직렬화된 형태를 총칭

공개 API :
그 API를 정의한 패키지의 밖에서 접근할 수 있는 API 요소로 이뤄진다.
모든 클라이언트가 접근할 수 있고, API 작성자가 지원하기로 약속한 API 요소들
( 자바독 javadoc 유틸리티를 기본 모드로 실행하면 이 API 요소들만 담긴 문서가 만들어진다. )

2장 객체 생성과 파괴

1. 생성자 대신 정적 팩터리 메서드를 고려하라.

클라이언트가 클래스의 인스턴스를 얻는 전통적인 수단은 public 생성자.

클래스는 생성자와 별도로 정적 팩터리 메서드(static factory method)를 제공할 수 있다.
(그 클래스의 인스턴스를 반환하는 단순한 정적 메서드)

정적 팩터리 메서드가 생성자보다 좋은 장점.
1. 이름을 가질 수 있다.
2. 호출될 때마다 인스턴스를 새로 생성하지는 않아도 된다.
3. 반환 타입의 하위 타입 객체를 반환할 수 있는 능력이 있다.
4. 입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다.
(반환 타입의 하위 타입이기만 하면 어떤 클래스의 객체를 반환하든 상관없다.)
5. 정적 팩터리 메서드를 작성하는 시점에는 반환활 객체의 클래스가 존재하지 않아도 된다.

*Big Integer(int, int, Random)

*자바 9에서는 private 정적 메서드까지 허락하짐나 정적 필드와 정적 멤버 클래스는 여전히 public이어야 한다.

*서비스 제공자 프레임워크는 3개의 핵심 컴포넌트로 이루어진다.
-> 서비스 인터페이스(구현체의 동작을 정의),
제공자 등록 API(제공자가 구현체를 등록할 때 사용),
서비스 접근 API(클라이언트가 서비스의 인스턴스를 얻을 때 사용 / 서비스 제공자 프레임워크의 근간이라고 한 '유연한 정적 팩터리'의 실체)

더불어 종종 서비스 제공자 인터페이스.라는 네 번째 컴포넌트가 쓰이기도 한다.
서비스 인터페이스의 인스턴스를 생성하는 팩터리 객체를 설명해 줌.
서비스 제공자 인터페이스가 없다면,
각 구현체를 인스터스로 만들 때 리플렉션을 사용해야 한다.
JDBC에서는 Connection : 서비스 인터페이스 역할,
DrvierManager.registerDriver가 제공자 등록 API 역할을,
DriverManager.getConnection이 서비스 접근 API 역할을,
Driver가 서비스 제공자 인터페이스 역할을 수행.

단점
1. 상속을 하려면 public이나 protected 생성자가 필요하니 정적 팩터리 메서드만 제공하면 하위 클래스를 만들 수 없다.
2. 정적 팩터리 메서드는 프로그래머가 찾기 어렵다.

*정적 팩터리 메서드에 흔히 사용하는 명명 방식들 (예시는 12p 참고)
from : 매개변수를 하나 받아서 해당 타입의 인스턴스를 반환하는 형변환 메서드
of : 여러 매개변수를 받아 적합한 타입의 인스턴스를 반환하는 집계 메서드
valueOf : from과 of의 더 자세한 버전
instance 혹은 getInstance : (매개변수를 받는다면) 매개변수로 명시한 인스턴스를 반환하지만, 같은 인스턴스임을 보장하지 않음.
create 혹은 newInstance : instance 혹은 getInstance와 같지만, 매번 새로운 인스턴스를 생성해 반환함을 보장.
getType : getInstance와 같으나, 생성할 클래스가 아닌 다른 클래스에 팩터리 메서드를 정의할 때 쓴다. "Type"은 팩터리 메서드가 반화할 객체의 타입이다.
newType : newInstance와 같으나, 생성할 클래스가 아닌 다른 클래스에 팩터리 메서드를 정의할 때 쓴다. "Type"은 팩터리 메서드가 반환할 객체의 타입이다.
type : getType과 newType의 간결한 버전

정적 팩터리 메서드와 public 생성자는 각자의 쓰임새가 있으니 상대적인 장단점을 이해하고 사용하는 것이 좋다.
그렇다고 하더라도 정적 팩터리를 사용하는 게 유리한 경우가 더 많으므로 무작정 public 생성자를 제공하던 습관이 있다면 고치자.

2. 생성자에 매개변수가 많다면 빌더를 고려하라

정적 팩터리와 생성자의 똑같은 제약
: 선택적 매개변수가 많을 때 적절히 대응하기 어렵다.

*자바빈즈 패턴(JavaBeans pattern) : 매개변수가 없는 생성자로 객체를 만든 후, 세터(setter) 메서드들을 호출해 원하는 매개변수의 값을 설정하는 방식
-> 객체 하나를 만들려면 메서드를 여러 개 호출해야 하고, 객체가 완전히 생성되기 전까지는 일관성(consistnecy)이 무너진 상태에 놓이게 된다. 라는 단점을 가지고 있다.

*빌더 패턴 : 명명된 선택적 매개변수(named optional parameters)를 흉내 낸 것, 계층적으로 설계된 클래스와 함께 쓰기 좋다.

생성자나 정적 팩터리가 처리해야 할 매개변수가 많다면 빌더 패턴을 선택하는 게 더 낫다.
매개변수 중 다수가 아니거나 같은 타입이면 특히 더 그렇다. 빌더는 점층적 생성자보다 클라이언트 코드를 읽고 쓰기가 훨씬 간결하고, 자바빈즈보다 훨씬 안전하다.

3. private 생성자나 열거 타입으로 싱글턴임을 보증하라
싱글턴(singleton)이란
인스턴스를 오직 하나만 생성할 수 있는 클래스.

만드는 방식

• 두 방식 모두 생성자는 private 으로 감춰두고, 유일한 인스턴스에 접근할 수 있는 수단으로 public static 멤버를 하나 마련.
• 정적 팩터리 메서드를 public static 멤버로 제공

4. 인스턴스화를 막으려거든 private 생성자를 사용하라
java.lang.Math
java.util.Arrays
처럼 기본 타입 값이나 배열 관련 메서드들을 모아놓을 수 있다.

java.tuil.Collections
처럼 특정 인터페이스를 구현하는 객체를 생성해주는 정적 메서드(혹은 팩터리)를 모아놓을 수도 있다.

final 클래스와 관련한 메서드들을 모아놓을 때도 사용

추상 클래스로 만드는 것으로는 인스턴스화를 막을 수 없다.
-> private 생성자를 추가하면 클래스의 인스턴스화를 막을 수 있다.

5.자원을 직접 명시하지 말고 의존 객체 주입을 사용하라.
많은 클래스가 하나 이상의 자원에 의존한다.

사용하는 자원에 따라 동작이 달라지는 클래스에는 정적 유틸리티 클래스나 싱글턴 방식이 적합하지 않다.
-> 인스턴스를 생성할 때 생성자에 필요한 자원을 넘겨주는 방식. 으로 사용하면 된다. (29p 예시 코드 참고)

클래스가 내부적으로 하나 이상의 자원에 의존하고, 그 자원이 클래스 동작에 영향을 준다면 싱글턴과 정적 유틸리티 클래스는 사용하지 않는 것이 좋다.
이 자원들을 클래스가 직접 만들게 해서도 안 된다.
대신 필요한 자원을 (혹은 그 자원을 만들어주는 팩터리를) 생성자에 (혹은 정적 팩터리나 빌더에) 넘겨주자.
의존 객체 주입이라 하는 이 기법은 클래스의 유연성, 재사용성, 테스트 용이성을 기막히게 개선해준다.

6.불필요한 객체 생성을 피하라
String.mathces는 정규표현식으로 문자열 형태를 확인하는 가장 쉬운 방법이지만, 성능이 중요한 상황에서 반복해 사용하기엔 적합하지 않다.
-> 성능을 개선하려면,
필요한 정규표현식을 표현하는 (불변인) Pattern 인스턴스를 클래스 초기화(정적 초기화) 과정에서 직접 생성해 캐싱해두고,
나중에 isRomanNumeral 메서드가 호출될 때마다 이 인스턴스를 재사용한다. (32p 코드 참고)

불필요한 객체를 만들어내는 또 다른 예로,
오토박싱(auto boxing)을 들 수 있다.
프로그래머가 기본 타입과 박싱된 기본 타입을 섞어 쓸 때 자동으로 상호 변환해주는 기술.

오토박싱은 기본 타입과 그에 대응하는 박싱된 기본 타입의 구분을 흐려주지만, 완전히 없애는 것은 아니다.
-> 박싱된 기본 타입보다는 기본 타입을 사용하고, 의도치 않은 오토박싱이 숨어들지 않도록 주의하자.

7.다 쓴 객체 참조를 해제하라

객체 참조를 null 처리하는 일은 예외적인 경우여야 한다.
다 쓴 참조를 해제하는 가장 좋은 방법은 그 참조를 담은 변수를 유효 범위(scope) 밖으로 밀어내는 것.

null 처리는 언제 해야 할까? Stack 클래스는 왜 메모리 누수에 취약한 걸까?
바로 스택이 자기 메모리를 직접 관리하기 때문.
이 스택(객체 자제가 아니라 객체 참조를 담는) elements 배열로 저장소 풀을 만들어 원소들을 관리한다.
-> 배열의 활성 영역에 속한 원소들이 사용되고,
비활성 영역은 쓰이지 않는다.
가비지 컬렉터는 이 사실을 알 길이 없어, 유요한 객체이므로 비활성 객체가 더 이상 쓸모 없다는 것은 프로그래머만 아는 사실이다.
그러므로 프로그래머는 비활성 영역이 되는 순간 null 처리해서 해당 객체를 더는 쓰지 않을 것임을 가비지 컬렉터에 알려야 한다.

자기 메모리를 직접 관리하는 클래스라면
프로그래머는 항시 메모리 누수에 주의해야 한다.

캐시 역시 메모리 누수를 일으키는 주범이다.
해법 방법

• WeakHashMap : 다 쓴 엔트리는 그 즉시 자동 제거
• Scheduled ThreadPoolExecutor 같은 백그라운드 스레드 : 시간이 지날수록 엔트리의 가치를 떨어뜨리는 방식을 흔히 사용하는데, 쓰지 않는 엔트리를 청소한다.
• LinkedHashMap, removeEldestEntry : 캐시에 새 엔트리를 추가
• java.lang.ref : 더 복잡한 캐시 만듦

메모리 누수의 세 번째 주범은
리스너(listener) 혹은 콜백(callback) :
클라이언트가 콜백을 등록만 하고 명확히 해지하지 않는다면,
뭔가 조치해주지 않는 한 콜백은 계속 쌓여갈 것이다.
이럴 때 콜백을 약한 참조(weak reference)로 저장하면 가비지 컬렉터가 즉시 수거해간다. (ex : WeakHashMap에 키로 저장)

메모리 누수는 겉으로 잘 드러나지 않아 시스템에 수년간 잠복하는 사례도 있다. 이런 누수는 철저한 코드 리뷰나 힙 프로파일러 같은 디버깅 도구를 동원해야만 발견되기도 한다. 그래서 이런 종류의 문제는 예방법을 익혀두는 것이 매우 중요

8.finalizer와 cleaner 사용을 피하라
두 가지 객체 소멸자

• finalizer
• cleaner

finalizer
: 예측할 수 없고, 상황에 따라 위험할 수 있어 일반적으로 불필요
오동작, 낮은 성능, 이식성 문제의 원인이 되기도 함.
기본적으로 '쓰지 말아야' 한다.

cleaner
: finalizer보다는 덜 위험하지만, 여전히 예측할 수 없고, 느리고, 일반적으로 불필요

둘 다 제때 실행되어야 하는 작업을 절대 할 수 없다.

수행 시점뿐 아니라 수행 여부조차 보장하지 않는다.
접근할 수 없는 일부 객체에 딸린 종료 작업을 전혀 수행하지 못한 채 프로그램이 중단 될 수도 있다는 얘기.
-> 상태를 영구적으로 수정하는 작업에선느 절대 둘 다 의존해서는 안 된다.

finalizer를 사용한 클래스는 finalzer 공격에 노출되어 심각한 보안 문제를 일으킬 수도 있다.
-> final이 아닌 클래스를 finalizer 공격으로부터 방어하려면 아무 일도 하지 않는 finalize 메서드를 만들고 final로 선언하자.

파일이나 스레드 등 종료해야 할 자원을 담고 있는 객체의 클래스에서 finalizer나 cleaner를 대신해줄 묘안 : AutoCloseable

AutoCloseable을 구현하고 클라이언트에서 인스턴스를 따 쓰고 나면 close메서드를 호출하면 된다.

cleaner(자바 8까지는 finalizer)는 안전망 역할이나 중요하지 않은 네이티브 자원 회수용으로만 사용하자. 물론 이런 경우라도 불확실성과 성능 저하에 주의해야 한다.

9.try-finally보다는 try-with-resources를 사용하라
자바 라이브러리에는 close 메서드를 호출해 직접 닫아줘야 하는 자원이 많다.
: InputStream, OutputStream, java.sql.Connection 등

자원 닫기는 클라이언트가 놓치지 쉬워서 예측할 수 없는 성능 문제로 이어지기도 한다.

전통적으로 자원이 제대로 닫힘을 보장하는 수단 : try-finally

꼭 회수해야 하는 자원을 다룰 때는 try-finall 말고, try-with-resources를 사용하자. 예외는 없다. 코드는 더 짧고 분명해지고, 만들어지는 예외 정보도 훨씬 유용하다.
try-finally로 작성하면 실용적이지 못할 만큼 코드가 지저분해지는 경우라도, try-with-resources로는 정확하고 쉽게 자원을 회수할 수 있다.

3장 모든 객체의 공통 메서드

Object
: 객체를 만들 수 있는 구체 클래스지만 기본적으로 상속해서 사용하도록 설계되어 있다.

final이 아닌 Object 메서드들을 언제 어떻게 재정의해야 하는지

1.equals는 일반 규약을 지켜 재정의하라
equals 메서드는 재정의하기 쉬워 보이지만 자칫하면 끔찍한 결과를 초래한다.

다음에 열거한 상황 중 하나에 해당한다면 재정의하지 않는 것이 최선.

• 각 인스턴스가 본질적으로 고유하다.
• 인스턴스의 '논리적 동치성(logical equality)'을 검사할 일이 없다.
• 상위 클래스에서 재정의한 equals가 하위 클래스에도 딱 들어맞는다.
• 클래스가 private이거나 package-private이고 equals 메서드를 호출할 일이 없다.

equals 메서드를 재정의할 때는 반드시 일반 규약을 따라야 한다.

equals 메서드는 동치관계(equivalence relation)을 구현하며, 다음을 만족 한다.

• 반사성
• 대칭성
• 추이성
• 일관성
• null아님

equals 규약을 어기면 그 객체를 사용하는 다른 객체들이 어떻게 반응할지 알 수 없음.

구체 클래스를 확장해 새로운 값을 추가하면서 equals 규약을 만족시킬 방법은 존재하지 않는다.

equals 메서드 단계별 구현 방법
1. == 연산자를 사용해 입력이 자기 자신의 참조인지 확인
2. instanceof 연산자로 입력이 올바른 타입인지 확인
3. 입력을 올바른 타입으로 형변환
4. 입력 객체와 자기 자신의 대응되는 '핵심' 필드들이 모두 일치하는지 하나씩 검사

꼭 필요한 경우가 아니면 equals를 재정의하지 말자. 많은 경우에 Object의 equals가 여러분이 원하는 비교를 정확히 수행해준다.
재정의해야 할 때는 그 클래스의 핵심 필드 모두를 빠짐없이, 다섯 가지 규약을 확실히 지켜가며 비교해야 한다.

2. equals를 재정의하려거든 hashCode도 재정의하라

hashCode 재정의를 잘못했을 때 크게 문제가 되는 것은 논리적으로 같은 객체는 같은 해시코드를 반환해야 한다는 것.

hashCode가 반환하는 값의 생성 규칙을 API 사용자에게 자세히 공표하지 말자.
그래야 클라이언트가 이 값에 의지하지 않게 되고, 추후에 계산 방식을 바꿀 수도 있다.

3. toString을 항상 재정의하라

toString을 잘 구현한 클래스는 사용하기에 훨씬 즐겁고, 그 클래스를 사용한 시스템은 디버깅하기 쉽다.

toString은 해당 객체에 관한 명확하고 유용한 정보를 읽기 좋은 형태로 반환해야 한다.

4. clone 재정의는 주의해서 진행하라
Cloneable :
복제해도 되는 클래스임을 명시하는 용도의 믹스인 인터페이스

실무에서 Cloneable을 구현한 클래스는 clone 메서드를 public으로 제공하며, 사용자는 당연히 복제가 제대로 이뤄지리라 기대한다.

5. Comparable을 구현할지 고려하라
CompareTo :
Compareable 인터페이스의 유일무이한 메서드
단순 동치성 비교에 더해 순서까지 비교할 수 있으며 제네릭하다.

compareTo 메서드에서 관계 연산자 <와> 를사용하는 이전 방식은 거추장스럽고 오류를 유발하니, 이제는 추천하지 않는다.