EFFECTIVE JAVA 3/E(이펙티브 자바 3/E 정리) - 1. 객체 생성과 파괴

이펙티브 자바 3/E 교재

 

어느 정도 자바 개발에 익숙해졌다면 한 번쯤 생각해보는 주제이다.

자기가 직접 구성한 코드 및 로직이 얼마나 효율적일까?

같은 결과를 도출하면서도 어느 게 더 성능적으로 우수한 프로그래밍일까 하는 생각 말이다.

 

물론 나도 현재 개발일을 하고 있지만 일의 데드라인이 있기 마련..

그 기한까지 요구한 기능을 어떤 방식을 사용하던 그 기능이 잘 돌아가는 것에만 포커스를 두었지,

내가 짠 코드가 올바르고 효율적인가에 대해서 생각을 많이 하지 않았었다.

 

기존에 선임개발자들이 짜놓은 코드가 좋은지 나쁜지 구별도 하지 않은 채복붙만 하던 코더 입장에서

좀 더 좋은 자바 개발자가 되겠다는 마음으로 이 책을 사서 챕터별로 이해하고 포스팅하도록 하겠다.

 

http://www.kyobobook.co.kr/product/detailViewKor.laf?mallGb=KOR&ejkGb=KOR&barcode=9788966262281

이펙티브 자바 3/E - 교보문고

 

 

1장 객체 생성과 파괴

---

생성자 대신 정적 팩토리 메소드를 기호에 맞게 사용하자

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

하지만 별도로 알아야 할 기법 중 하나는 생성자와 별도로 정적 팩토리 메소드(static factory method)를 제공할 수 있다.

 

정적 팩토리의 장점

 1. 정적 팩토리의 이름만 잘 구성한다면 반환될 객체의 특성을 쉽게 묘사할 수 있다.

    - 헷갈리지 않고 명확한 이름을 가질 수 있다.

 2. 호출될 때마다 인스턴스를 새로 생성하지 않아도 된다.

    - 생성 비용이 큰 오브젝트를 자주 요청하는 상황이라면 성능을 상당히 끌어올려준다.

 3. 반환 타입의 하위 타입 객체를 반환할 수 있다.

    - 하위 타입 객체를  반환하는 유연성을 가진다.

 4. 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다.

    - 반환 타입의 하위 타입이기만 하면 어떤 클래스의 객체를 반환하든 상관없다.

 5. 정적 팩토리 메소드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다.

 

정적 팩토리의 단점

 1. 상속을 하려면 public / protected 생성자가 필요하여 정적 팩토리 메소드만 제공하면 하위 클래스를 만들 수 없다.

 2. 프로그래머가 찾기 어렵다.

     - 생성자처럼 API 설명에 명확히 드러나지 않으니 이런 방식의 클래스를 인스턴스화할 방법을 알아내야 한다.

 

 핵심정리
정적 팩토리 메소드와 생성자는 각자의 쓰임새가 있으니 장단점을 이해하고 사용하는 것이 좋다.
정적 팩토리 메소드를 사용하는 것이 유리한 경우가 많으니 무작정 생성자를 쓰지말아야 한다.

     

---

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

 

정적 팩토리와 생성자에는 똑같은 제약이 있다.

선택적 매개변수가 많을 때 적절히 대응하기 어렵다는 점이다.

많은 프로그래머들은 이럴 경우 점층적 생성자 패턴을 사용했다.

하지만 이방법은 매개변수 개수가 많아지면 코드를 작성하거나 읽기가 힘들어진다.

 

자바빈즈 패턴(JavaBeans pattern) 

- 점층적 생성자 패턴의 두번째 대안으로 자바빈즈 패턴이 있다.

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

자바빈즈 패턴의 장점

  1. 점층적 생성자 패턴의 단점들이 없다. 

  2. 코드는 조금 길어지지만 인스턴스를 만들기 쉽고, 그 결과 더 읽기 쉬운 코드가 된다.

자바빈즈 패턴의 단점

  1. 객체 하나를 만들려면 메소드를 여러개 호출해야 한다.

  2. 객체가 완전히 생성되기 전까지 일관성이 무너진 상태에 놓이게 된다.

  3. 자바빈즈 패턴에서는 클래스를 불변으로 만들 수 없으며 스레드 안전성을 얻으려면 추가 작업을 해줘야 한다.

 

이런 자바 빈즈 패턴도 다루기가 까다로워 실전에서는 거의 쓰이지 않는다.

이런 대안으로 점층적 생성자 패턴의 안전성과 자바빈즈의 패턴의 가독성을 겸비한 빌더 패턴이 있다.

 

빌더 패턴(Builder pattern) 

- 클라이언트는 필요한 객체를 직접 만드는 대신, 필수 매개변수만으로 생성자 or 정적 팩토리를 호출해 빌더 객체 얻는다.

- 빌더 객체가 제공하는 일종의 세터 메소드들로 원하는 매개변수들을 설정한다.

- 매개변수가 없는 bulid 메소드를 호출해 필요한 객체를 얻는다.

 

빌더 패턴의 장점

  1. 코드를 쓰기 쉽다.

  2. 읽기 쉽다.

  3. 계층적으로 설계된 클래스와 함께 쓰기에 좋다.

  4. 상당히 유연하다.

      - 빌더 하나로 여러 객체를 순회하면서 만들 수 있고, 빌더에 넘기는 매개변수에 따라 다른 객체를 만들 수도 있다.

   

---

private 생성자나 열거 타입으로 싱글턴임을 보증하라

 

싱글턴(singleton)이란 인스턴스를 오직 하나만 생성할 수 있는 클래스를 말한다.

클래스를 싱글턴으로 만들면 이를 사용하는 클라이언트를 테스트하기가 어려워 질 수 있다.

 

public static final 필드 방식의 싱글턴

클래스가 초기화될 때 만들어진 인스턴스가 전체 시스템에서 하나뿐임을 보장한다.

해당 클래스가 싱글턴임이 API에 명백히 드러난다.

 public static 필드가 final이니 절대로 다른 객체를 참조할 수 없다.

 

정적 팩토리 방식의 싱글턴

항상 같은 객체의 참조를 반환한다. 

API를 바꾸지 않고도 싱글턴이 아니게 변경할 수 있다.

정적 팩토리를 제네릭 싱글턴 팩토리로 만들 수 있다.

정적 팩토리의 메소드 참조를 공급자로 사용할 수 있다.

 

위 싱글턴 방식 둘 중 하나의 방식으로 만든 싱글턴 클래스를 직렬화하려면 단순이 Serializable을 구현한다고 선언하는 것만으로 부족하다.

인스턴스 필드를 일시적이라 선언하고 readResolve 메소드를 제공해야 한다. 

직렬화된 인스턴스를 역직렬화할 때마다 새로운 인스턴스가 만들어져 가짜 클래스가 탄생할 수도 있다.

 

열거 타입 방식의 싱글턴

public 필드 방식과 비슷하지만 간결하고 추가 노력 없이 직렬화할 수 있다.

아주 복잡한 직렬화 상황이나 리플렉션 공격에도 제2의 인스턴스가 생기는 불상사를 완벽히 막아준다.

원소가 하나뿐인 열거 타입이 싱글턴을 만드는 가장 좋은 방법이다.

 

---

인스턴스화를 막으려거든 private 생성자를 사용하라

 

정적 메소드와 정적 필드만을 담은 클래스를 만들고 싶을 때가 있다.

객체 지향적으로 사고하지 않는 방식이지만 쓰임새가 있다.

정적 멤버만 담은 유틸리티 클래스는 인스턴스로 만들어 쓰려고 설계한게 아니다.

생성자를 명시하지 않으면 컴파일러가 자동으로 기본 생성자를 만들어 준다.

매개변수를 받지 않는 public 생성자가 만들어지며, 사용자는 자동 생성된 것인지 구분할 수 없다.

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

---

자원을 직접 명시하지 말고 의존 객체 주입을 사용하라

 

클래스가 내부적으로 하나 이상의 자원에 의존하고, 그 자원이 클래스 동작에 영향을 준다면 싱글턴과 정적 유틸리티 클래스는 사용하지 않는 것이 좋다.

이 자원들을 클래스가 직접 만들게 해서도 안된다.

대신 필요한 자원을 (혹은 그 자원을 만들어주는 팩토리를) 생성자 or 정적 팩토리 or 빌더에 넘겨주자. 

의존 객체 주입이라 하는 이 기법을 클래스의 유연성, 재사용성, 테스트 용이성을 개선해준다.

---

불필요한 객체 생성을 피하라

 

String s = new String("abc");

위와 같은 코드는 실행될 때마다 String 인스턴스를 새로 만들어 불필요한 인스턴스가 계속 만들어질 수 있다.

String s = "abc";

위 코드는 인스턴스를 매번 만드는 대신 하나의 String 인스턴스를 사용한다. 

 

Boolean(String) 보다는 Boolean.valueOf(String)

matches 보다는 Pattern 을 사용하자.

---

다 쓴 객체 참조를 해제하라

 

GC(Garbage Collection)은 다 쓴 객체를 알아서 회수 한다고 해서 메모리 관리에 신경을 쓰지 않아도 된다고 생각하지만 절대 아니다.

스택이 커졌다가 줄어들었을 때 스택에서 꺼내진 객체들을 가비지 컬렉터가 회수 하지 않는다.

그 객체들을 더 이상 사용하지 않더라도 회수 하지 않는다.

이 스택이 객체들의 다 쓴 참조를 여전히 가지고 있기 때문이다. 

해법은 참조를 다 썼을 때 null 처리 (참조 해제) 하면 된다.

그렇다고 일일이 null 처리하는 것은 바람직 하지 않다. 

객체 참조를 null 처리하는 일은 예외적인 경우여야 한다.

다 쓴 참조를 해제하는 가장 좋은 방법은 그 참조를 담은 변수를 유효 범위 밖으로 밀어내는 것이다.

---

finalizer와 cleaner 사용을 피하라

 

finailzer는 예측할 수 없고, 상황에 따라 위험할 수 있어 일반적으로 불필요하다.

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

이 둘은 즉시 숭행된다는 보장이 없다. 

객체에 접근할 수 없게 된 후 finalizer나 cleaner가 실행되기까지 얼마나 걸릴지 알 수 없다.

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

상태를 영구적으로 수정하는 작업에서는 절대 의존해서는 안된다.

심각한 성능 문제도 동반하며, 공격에 노출되어 심각한 보안 문제를 일으킬 수도 있다.

 

대신해줄 대안은 AutoCloseable을 구현해주고, 인스턴스를 다 사용하고  close 메소드를 호출 하면 된다. 

---

try-finally 보다는 try-with-resources를 사용하라

 

자바 라이브러리에는 close 메소드를 호출해 직접 닫아줘야 하는 자원이 많다. 

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

전통적으로 닫힘을 보장하는 수단으로 try-finally가 쓰였다. 

하지만 자원이 둘 이상이면 너무 지저분해진다.

두번째 예외가 첫 번째 예외를 완전히 집어삼켜 버려 스택 추적 내역에 첫 번째 예외에 대한 정보는 남지 않는다.

디버깅을 어렵게 만드는 요인이다.

이 대안으로 try-with-resources 가 있다. 

 

try-with-resources

이 구조를 사용하려면 해당 자원이 AutoCloseable 인터페이스를 구현해야 한다.

단순히 void를 반환하는 close 메소드 하나만 정의한 인터페이스이다. 

이 구조는 짧고 읽기 수월할 뿐 아니라 문제를 진단하기도 좋다. 

close 호출 양쪽에서 예외가 발생하면 문제가 발생한 구간에서 예외가 기록된다.

예외 하나만 보존되고 여러 개의 다른 예외가 숨겨질 수도 있다.

단순히 버려지지 않고, 스택 추적 내역에 숨겨졌다(suppressed)는 꼬리표를 달고 출력된다. 

정확하고 쉽게 자원을 회수할 수 있다.