Java

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

점층적 생성자 패턴

프로그래머들은 이럴 때 **점층적 생성자 패턴(telescoping constructor pattern)**을 즐겨 사용했다.

점층적 생성자 패턴은 매개변수 개수가 많아지면 클라이언트 코드를 작성하거나 읽기 어렵다.

자바빈즈 패턴

매개변수가 없는 생성자로 객체를 만든 후, 세터(setter) 메서드를 호출해 원하는 매개변수의 값을 설정하는 방식이다.

객체 하나를 만들려면 메서드를 여러 개 호출해야 하고, 객체가 완전히 생성되기 전까지는 일관성(consistency)이 무너진 상태에 놓이게 된다.

이러한 단점을 완화하고자 생성이 끝난 객체를 수동으로 '얼리고(freezing)', 얼리기 전에는 사용할 수 없도록 하기도 한다.

이 방법을 쓴다고 하더라도 객체 사용 전에 프로그래머가 freeze 메서드를 확실히 호출해줬는지를 컴파일러가 보증할 방법이 없어서 런타임 오류에 취약하다.

빌더 패턴

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

점층적 생성자 패턴의 안전성과 자바빈즈 패턴의 가독성을 겸비한 빌더 패턴(Builder pattern)

Java에서 Enum을 지원하기 전에는 아래와 같이 정수 상수를 한 곳에 선언해서 사용하곤 했다

이러한 방식을 정수 열거 패턴(int enum pattern)이라고 하는데, 여기에는 단점이 많다

정수 열거 패턴(int enum pattern)의 단점

타입 안전을 보장할 방법이 없다

표현력이 좋지 않다

정수 상수는 문자열로 출력하기 다소 까다롭다

문자열 열거 패턴(string enum pattern)은 더욱 좋지 않은 방법이다 상수의 의미를 출력할 수 있다는 장점만 있을 뿐, 하드코딩이 불가피하며 오타가 있어도 컴파일러가 확인할 방법이 없다. 또한, 문자열 비교에 따른 성능 저하 역시 발생한다

같은 정수 열거 그룹에 속한 모든 상수를 한 바퀴 순회하는 방법도 마땅치 않다

열거 타입(Enum Type)? JLS 8.9

[Item-34] int 상수 대신 열거 타입을 사용하라

Effective Java 3E

전통적으로 도구나 프레임워크가 특별히 다뤄야 할 프로그램 요소에는 딱 구분되는 명명 패턴을 적용해왔다

예를들면 JUnit 버전 3까지는 테스트 메서드 이름을 test로 시작하게끔 했다

효과적인 방법이지만 단점도 크다

명명 패턴의 단점

예전에는 자바에서 함수 타입을 표현할 때 추상메서드를 하나만 담은 인터페이스(드물게는 추상클래스)를 사용했었다

전략패턴처럼, 함수 객체를 사용하는 과거 객체 지향 디자인 패턴에는 익명 클래스면 충분했다

하지만 익명 클래스 방식은 코드가 너무 길기 때문에 자바는 함수형 프로그래밍에 적합하지 않았다

람다식의 등장

자바 8에 와서 추상 메서드 하나짜리 인터페이스는 특별한 의미를 인정받아 특별한 대우를 받게 되었다

지금은 함수형 인터페이스라 부르는 이 인터페이스들의 인스턴스를 람다식(lambda exression)을 사용해 만들 수 있게 된것이다

여기서 람다, 매개변수 (s1, s2) 반환값의 타입은 코드에서는 언급이 없어도 컴파일러가 문맥을 살펴 타입을 추론해준다

[Item-42] 익명 클래스보다는 람다를 사용하라

타입을 명시해야 람다 코드가 더 명확해지는 경우를 제외하고는 모든 매개변수 타입은 생략하도록 하자

Period 클래스는 한번 값이 정해지면 변하지 않도록 하기 위해 final 클래스로 선언하였다

생성자에서 받은 가변 매개변수 각각을 방어적으로 복사하라

언뜻보면 불변처럼 보이는 이 Period 클래스는 Date가 가변이라는 사실을 이용하면 쉽게 불변식을 깨뜨릴 수 있다

위 코드에 대해서 몇가지 알아야 할 점은

Date는 Deprecated API이므로 이제는 사용하지 말아야 한다

하지만 꼭 Date 클래스만의 문제가 아니므로 다음 방법을 보자

Date 대신 immutable인 LocalDate나 LocalDateTime을 쓴다면 해결가능하다

→ 매개변수의 유효성을 검사하기 전에 방어적 복사본을 만들고, 이 복사본으로 유효성을 검사하자

순서가 부자연스러워 보일 수 있지만, 반드시 이렇게 작성해야한다

[Item50] 적시에 방어적 복사본을 만들라

컬렉션을 순회할 때 전통적인 for 문은 다음과 같다.

우리에게 진짜 필요한 건 원소들인데, 반복자와 인덱스 변수는 코드를 지저분하게 한다.

Enhanced for statement(향상된 for 문)

java 1.5부터 도입된 for-each는 하나의 관용구로 컬렉션과 배열을 모두 처리할 수 있어서

어떤 컨테이너를 다루는지는 신경쓰지 않아도 된다.

for-each 문은 컬렉션을 중첩해서 사용해야 할 때 이점이 더욱 커진다

아래 코드에서 버그를 찾아보자

위 코드를 실행시켜 보면 NoSuchElementException이 발생한다.

[Item58] 전통적인 for문 보다는 for-each 문을 사용하라

메서드가 던지는 예외는 그 메서드를 올바르게 사용하는데 아주 중요한 정보다.

따라서 각 메서드가 던지는 예외 하나하나를 문서화하는데 충분한 시간을 쏟아야 한다.

검사 예외(Checked Exception)는 항상 따로따로 선언하고, 각 예외가 발생하는 상황을 자바독의 @throws 태그를 사용하여 정확히 문서화하자

공통 상위 클래스 하나로 뭉뚱그려 선언하는 일은 삼가하자

같은 맥락에서 발생할 여지가 있는 다른 예외들까지 삼켜버릴 수 있다

메서드가 던질 수 있는 예외를 각각 @throws 태그로 문서화하되, 비검사 예외는 메서드 선언의 throws 목록에 넣지 말자

비검사 예외(Unchecked Exception)도 정성껏 문서화 해두면 그 자체만으로도 메서드를 잘 수행하기 위한 전제조건이 되어 좋다

특히 인터페이스 메서드에서 구현한 모든 구현체가 일관되게 동작하도록 해주기 때문에 특히 중요하다

[Item74] 메서드가 던지는 모든 예외를 문서화하라

하지만 검사냐, 비검사냐에 따라 API 사용자가 해야할 일이 달라지므로 둘을 확실히 구분해주는게 좋다

스레드 안전성(Thread-safe) 수준을 문서화 하지 않으면 클래스 사용자는 나름의 가정을 해야만 한다.

만약 그 가정이 틀리면 클라이언트 프로그램은 동기화를 충분히 하지 못하거나 지나치게 한 상태일 것이며 이 경우 모두 심각한 오류로 이어질 수 있다.

synchronized 한정자를 선언했는데?

소스 코드에 synchronized 한정자를 사용했다고 하더라도 이는 구현상에서만 쓰일 뿐 JavaDoc 기본 옵션에서 생성한 API 문서에는 드러나지 않는다

즉, synchronized 한정자를 선언하였다고 해서 Thread-safe함을 문서화 한 것이 아니다!

synchronized 한정자를 사용했다고해서 그 클래스가 100% Thread-safe한가?

스레드 안전성에도 수준이 나뉜다. 멀티스레드 환경에서도 API를 안전하게 사용하게 하려면 클래스가 지원하는 스레드 안전성 수준을 전확히 명시해야 한다.

다음은 스레드 안전성이 높은 순으로 나열한것이다.

(스레드 안전성 어노테이션과 유사한 것을 ≈ 통해 표현)

불변(immutable)  ≈  @Immutable
: 이 클래스의 인스턴스는 마치 상수와 같아서 외부 동기화가 필요 없다 (ex. String, Long, BigInteger)

[Item82] 스레드 안전성 수준을 문서화하라

무조건적 스레드 안전(unconditionally thread-safe)  ≈  @ThreadSafe
: 우리가 흔히 얘기하는 thread-safe한 클래스로 별도의 동기화 없이 동시에 사용해도 안전하다 (ex. AtomicLong, ConcurrentHashMap)

정상적인 인스턴스 생성 방법인 생성자 이외의 방법이 생기게 된다. 버그와 보안 문제가 생길 가능성이 커진다는 것이다.

Serializable을 implements한 순간

하지만 직렬화 프록시 패턴을 사용하면 위험을 크게 줄일 수 있다.

직렬화 프록시 패턴

바깥 클래스의 논리적 상태를 표현하는 중첩 클래스를 설계하여 private static으로 선언한다. 여기서 중첩 클래스가 직렬화 프록시다.

중첩 클래스의 생성자는 단 하나여야 하며, 바깥 클래스를 매개변수로 받아야 한다. 단순히 인수로 넘어온 인스턴스의 데이터를 복사한다. 일관성 검사 또는 방어적 복사도 필요가 없다.

다만 바깥 클래스와 직렬화 프록시 모두 Serializable을 구현해야 한다.

직렬화 프록시 패턴의 장점

앞선 예제 코드에서 본 것처럼 멤버 필드를 final로 선언할 수 있기 때문에 진정한 불변으로 만들 수 있다.

또한 직렬화 프록시 패턴은 역직렬화한 인스턴스와 원래의 직렬화된 클래스가 달라도 정상적으로 동작한다.

대표적인 예로 EnumSet은 public 생성자 없이 정적 팩터리만 제공한다. 원소 개수가 64개 이하면 RegularEnumSet을 사용하고 그보다 크면 JumboEnumSet을 사용한다.

그런데, 64개짜리 원소를 가진 EnumSet을 직렬화한 다음에 원소 5개를 추가하고 역직렬화하면 어떻게 될까?

간단히 역직렬화할 때 JumboEnumSet으로 하면 된다. 이게 가능한 이유는 EnumSet에는 직렬화 프록시 패턴이 적용되어 있기 때문이다.

[Item-90] 직렬화된 인스턴스 대신 직렬화 프록시 사용을 검토하라

람다는 직렬화 해서는 안되는 이유

람다도 익명 클래스처럼 직렬화 형태가 구현별로(가령 가상머신별로) 다를 수 있다. 따라서 람다를 직렬화하는 일은 극히 삼가야 한다(익명 클래스의 인스턴스도 마찬가지다)  - p.285 -

오라클 공식문서에서도 람다 표현식과 익명 클래스에 대한 직렬화를 '강력하게' 권장하지 않다

그 이유는 람다 표현식이나 익명 클래스에 대해서 직렬화를 할 때, 자바 컴파일러가 특정 구문에 대해서 Synthetic constructs(인조 구문이 맞는 번역 같음)을 삽입하는데 이 Synthetic constructs는 컴파일러의 구현 방식에 따라서 다를 수 있다. 이 의미는 '.class' 파일도 컴파일러 구현에 따라 다를 수 있음을 의미한다. [내용 보기]

결과적으로 위의 이유에 의해서 다른 컴파일러를 사용하고 있는 경우 호환성의 문제가 발생할 수 있기 때문에 직렬화를 하는것은 강하게 권장하지 않는다!

람다를 직렬화 하는 방법

하지만 때에 따라서 람나 표현식이나 익명 클래스가 포함된 클래스를 직렬화를 해야할 때도 있을 수 있다

먼저, 람다가 정의된 클래스를 냅다 직렬화/역직렬화를 해보자

[Item42] 람다는 직렬화 해서는 안된다

Effective Java 3E

스트림은 Java 8부터 추가된 API로 선언형으로 컬렉션 데이터를 처리할 수 있다(컬렉션에 스트림을 반환하는 stream 메서드가 추가됨)

스트림(Stream)이란?

또한, 스트림을 이용하면 멀티스레드 코드를 구현하지 않아도 데이터를 투명하게 병렬로 처리할 수 있다.

menu라는 음식들 들어있는 리스트에서 칼로리가 400 미만인 음식을 찾아서, 이름을 추출한 뒤, 이름들이 정렬되어 저장된 리스트를 만드는 과정을 스트림을 사용하지 않은 코드와 사용한 코드에 대해서 비교해보자

예시에서 볼 수 있듯이 훨씬 간결하고 명확하며 가독성이 좋은 소스코드를 짤 수 있다. 또한, lowCaloricDishes와 같이 불필요한 변수를 생성하지도 않는다. 여기서는 성능적인 차이는 크게 없지만, 스트림의 parallelStream()을 사용한다면 멀티코어 아키텍처에서 병렬로 실행하여 성능을 더 개선시킬 수 있다 (자세한 내용은 저 아래에서)

즉, 스트림을 쓰면 아래와 같은 특징을 얻을 수 있다

선언형으로 더 간결하고 가독성이 좋은 코드를 짤 수 있다

조립하여 쓸 수 있으므로 유연성이 좋아진다