아이템 1. 생성자 대신 정적 팩터리 메서드를 고려하라
public static Boolean valueOf(boolean b){
return b ? Boolean.TRUE : Boolean.FALSE;
}
정적 팩터리 메서드의 장점
이름을 가질 수 있다.
생성자에게 넘기는 매개변수와 생성자 자체만으로는 반활될 객체의 특성을 제대로 설명하지 못한다. 정적 팩터리는 이름만 잘 지으면 반환될 객체의 특성을 쉽게 묘사할 수 있다.
예
생성자 : BigInteger(int, int, Random)
정적 팩터리 : BigInteger.probablePrime
호출될 때마다 인스턴스를 새로 생성하지 않아도 된다.
불변 클래스(immutable class)는 인스턴스를 미리 만들어 놓거나 새로 생성한 인스턴스를 캐싱하여 재활용하는 식으로 불필요한 객체 생성을 피할 수 있다.
생성 비용이 큰 같은 객체가 자주 요청되는상황이라면 선능을 상당히 끌어올려준다.
정적 팩터리 방식은 인스턴트를 철저히 통제할 수 있다. 이런 클래스를 인스턴스 통제(instance-controlled) 클래스라 한다.
예
반환 타입의 하위 타입 객체를 반환할 수 있는 능력이 있다.
입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다.
반환 타입의 하위 타입이기만 하면 어떤 클래스의 객체를 반환하든 상관없다.
EnumSet 클래스는 public 생성자 없이 오직 정적 팩터리만 제공하는데, OpenJDK에서 원소의 수에 따라 두가지 하위 클래스 중 하나의 인스턴스를 반환한다.
즉, 클라이언트는 팩터리가 건네주는 객체가 어느 클래스의 인스턴스인지 알 수도 없고 알 필요도 없다. EnumSet의 하위 클래스이기만 하면 된다.
정적 팩터리 메서드를 작성하는 시점에는 반환할 객체의 클래스가 존재하지 않아도 된다.
서비스 제공자 프레임워크(service provider framework)를 만드는 근간이된다. (대표적으로 jdbc가 있음)
서비스 제공자 프레임워크에서의 제공자는 서비스 구현체이다. 이 구현체들은 클라이언트에 제공하는 역할을 프레임워크가 통제하여, 클라이언트를 구현체로부터 분리해준다.
클라이언트는 서비스 접근 API를 사용할 때 원하는 구현체의 조건을 명시할 수 있다. (유연한 정적팩터리라고 하는 이유)
서비스 제공자 프레임궈크는 3개의 핵심 컨포넌트가 있다.
서비스 제공자 프레임워크 패턴에는 여러 변형이 존재한다.
정적 팩터리 메서드의 단점
상속을 하려면 public 이나 protected 생성자가 필요하니 정적 팩터리 메서드만 제공하면 하위 클래스를 만들 수없다.
상속보다 컴포지션을 사용하도록 유도하고 불변 타입으로 만들려면 이 제약을 지켜야 한다는 점에서 오히려 장점으로 받아들일 수도 있다.
정적 팩터리 메서드는 프로그래머가 찾기 어렵다.
생성자처럼 API설명에 명확히 드러나지 않으니 사용자는 정적 팩터리 메서드 방식 클래스를 인스턴스화할 방법을 알아내야 한다. 따라서 API문서를 잘 써 놓고 메서드명도 널리 알려진 규약을 따라 짓는 식으로 문제를 완화시켜야한다.
from : 매개변수를 하나 받아서 해당 타입의 인스턴스를 반환하는 형변환 메서드
of : 여러 매개변수를 받아 적합한 타입의 인스턴스를 반환한다.
valueOf : from 과 of의 더 자세한 버전
instance, getInstance : 매개변수로 명시한 인스턴스를 반환하지만, 같은 인스턴스임을 보장하지 않는다.
create, newInstance : instance 혹은 getInstance와 같지만, 매번 새로운 인스턴스를 생성해 반환함을 보장한다.
getType : getInstance와 같으나, 생성할 클래스가 아닌 다른 클래스에 팩터리 메서드를 정의할 때 쓴다. "Type"은 팩터리 메서드가 반환할 객체의 타입이다.
newType : newInstance와 같으나, 생성할 클래스가 아닌 다른 클래스에 팩터리 메서드를 정의할 때 쓴다. "Type"은 팩터리 메서드가 반환할 객체의 타입이다.
type : getType과 newType의 간결한 버전
아이템 2. 생성자에 매개변수가 많다면 빌더를 고려하라
선택적 매개변수가 많은 경우 대부분 점층적 생성자 패턴을 사용한다. 하지만 매개변수가 많아지면 클라이언트 코드를 작성하거나 읽기가 어려워진다.
다른 방법으론 매개변수가 없는 생성자로 객체를 만든 후 setter 메서드들을 호출해 원한느 매개변수의 값을 설정하는 방식인 자바빈즈패턴도 있다.
객체 하나를 만들려면 메서드를 여러 개 호출해야 하고, 객체가 완전히 생성되기 전까지는 일관성이 무너진 상태에 놓이는 단점이 있다. (불변(17장참조)으로 만들 수도 없다.)
단점을 보완하고자 생성이 끝난 객체를 수동으로 freezing, freezing 전에는 사용할 수 없도록 하기도 한다. 하지만 이 방법은 다루기가 어려워서 실전에 거의 쓰이지 않는다.
점층적 생성자 패턴의 안전성과 자바 빈즈 패턴의 가독성을 겸비한 빌더 패턴(Builder pattern)이다. --> p17 예제 확인
과정
클라이언트는 필요한 객체를 직접 만드는 대신, 필수 매개변수만 생성자(혹은 정적 팩터리)를 호출해 빌더 객체를 얻는다.
빌더 객체가 제공하는 일종의 setter 메서드들로 원하는 선택 매개변수들을 설정한다.
마지막으로 매개변수가 없는 build 메서드를 호출해 필요한 객체를 얻는다.
공격에 대비해 이런 분변식을 보장하려면 빌더로 부터 매개변수를 복사한 후 해당 객체 필드들도 검사해야한다. 검사 후 잘못된 점을 발견하면 어떤 매개변수가 잘못되었는지를 자세히 알려주는 메시지를 담아 IllegalArgumentException을 던지면 된다.
빌더 패턴은 계층적으로 설계된 클래스와 함께 쓰이기 좋다. 각 하위 클래스의 빌더가 정의한 build 메서드는 해당하는 구체 하위 클래스를 반환하도록 선언한다. 하위 클래스의 메서드가 상위 클래스의 메서드가 정의한 반환 타입이 아닌, 그 하위 타입을 반환하는 기능을 공변반환 타이핑(covariant return typing)이라 한다. --> p20 예제
장점
생성자로는 누릴 수 없는 사소한 이점으로, 빌더를 이용하면 가변인수(varargs)매개변수를 여러 개 사용할 수 있다.
빌더 하나로 여러 객체를 순회하면서 만들 수 있고, 빌더에 넘기는 매개변수에 따라 다른 객체를 만들 수도 있다. 객체마다 부여되는 일변번호와 같은 특정 필드는 빌더가 알아서 채우도록 할 수 있다. (매우 유연하다)
단점
객체를 만들려면, 그에 앞서 빌더부터 만들어야한다. 빌더 생성 비용이 크지는 않지만 성능에 민감한 상황에서는 문제가 될 수 있다.
점층적 생성자 패턴보다 코드가 장황해서 매개변수가 많아지는 경향이 있다. (하지만 API도 시간이 지날수록 많아진다)
아이템 3. private 생성자나 열거 타입으로 싱글턴임을 보증하라
싱글턴(Singletion)이란 인스턴스를 오직 하나만 생성할 수 있는 클래스를 말한다. (예, 무상태(ststeless)객체나 설계상 유일해야 하는 시스템 컴포넌트)
하지만 싱글턴으로 클래스를 만들 경우 이를 사용하는 클라이언트를 테스트하기가 어려워질 수 있다. (단위 테스트) 그 이유는 싱글턴의 인스턴스를 Mock으로 구현 으로 대체할 수 없기 때문이다.
싱글턴 만드는 방식
// 싱글턴임을 보장해주는 readResolve 메서드
private Object readResolve(){
// '진짜' Elvis를 반환하고, 가짜 Elvis는 가비지 컬렉터에 맡긴다.
return INSTANCE;
}
원소가 하나인 열거 타입을 선언하는 방식
public 필드 방식과 비슷하지만, 더 간결하고, 추가 노력 없이 직렬화할 수 있고, 심지어 아주 복잡한 직렬화 상황이나 리플렉션 공격에서도 제2의 인스턴스가 생기는 일을 완벽히 막아준다.
대부분 상황에서는 원소가 하나뿐인 열거 타입이 싱글턴을 만드는 가장 좋은 방법이다.
단, 만들려는 싱글턴이 Enum 외의 클래스를 상송해야 한다면 이 방법은 사용할 수 없다.
예
public enum Elvis {
INSTANCE;
public void leaveTheBuilding() {...}
}
아이템 4. 인스턴스화를 막으려거든 private 생성자를 사용하라
정적 멤버만 담은 유틸리티 클래스(추상클래스)는 인스턴스로 만들어 쓰려고 설계한 게 아니다. 하지만 생성자를 명시하지 않으면 컴파일러가 자동으로 기본 생성자를 만들어준다.
즉, 추상 클래스로 만드는 것으로는 인스턴스화를 막을 수 없다. 하위클래스에서 인스턴스화 하면 되기 때문이다.
이를 막기 위해선 private 생성자를 추가하면 클래스의 인스턴스화를 막을 수 있다. 이유는 컴파일러가 기본 생성자를 만드는 경우 오직 명시된 생성자가 없을 때이기 때문이다.
아이템 5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라
private final Lexicon dictionary;
public SpellChecker(Lexicon dictionary){
this.dictionary = Object.requireNonNull(dictionary);
}
자원이 몇개든 의존 관계가 어떻든 상관없이 잘 동작하고, 불변을 보장하며, 여러 클라이언트가 의존 객체들을 안심하고 공유할 수 있기도하다. (의존 객체 주입은 생성자, 정적 팩터리, 빌더 모두에 응용가능)
단점으로는 의존 객체 주입이 유연성과 테스트 용이성을 개선해주긴 하지만 의존성이 수천개나 되는 큰 프로젝트에서는 코드를 어지럽게 만들기도 한다. (Spring과 같은 의존 객체 주입 프레임워크를 사용하면 개선됨)
아이템 6. 불필요한 객체 생성을 피하라
String s = new String("aa");
String s = "aa";
private static final Pattern ROMAN = Pattern.compile();
static boolean isRomanNumeral(String s){
return ROMAN.matcher(s).matches();
}
private static long sum(){
Long sum = 0L;
for (long i = 0; i <= Integer.MAX_VALUE; i++)
sum += i;
return sum
}
sum 변수를 long이 아닌 Long으로 선언해서 불필요한 Long 인스턴스가 약 231개나 만들어진 것이다.
즉, 박싱된 기본 타입보다는 기본 타입을 사용하고, 의도치 않은 오토박싱이 숨어들지 않도록 주의하자.
객체 생성은 비싸니 피해야한다라고 오해를 하면 안된다. 요즘 JVM에서 별다른 일을 하지 않는 작은 객체를 생성하고 회사하는 일이 크게 부담되지 않는다. 프로그램의 명확성, 간결성, 기능을 위해서 객체를 추가로 생성하는 것이라면 일반적으로 좋은 일이다.
아주 무거운 객체가 아닌 다음에야 단순히 객체 생성을 피하고자 여러분만의 객체 풀을 만들지는 말자. 데이터베이스 연결 같이 무거운 객체를 사용하는 경우, 생성 비용이 워낙 비싸니 재사용하는 것이 좋다.
아이템 7. 다 쓴 객체 참조를 해제하라
자바는 GC가 다 쓴 객체를 알아서 회수하기 때문에 메모리 관리에 더 이상 신경쓰지 않아도 된다고 생각한다. 하지만 메모리 누수로 프로그램이 오래 실행되다 보면 점차 컬렉션 활동과 메모리 사용량이 늘어나 결국 성능이 저하될 것이다. (심한 경우 디스크 페이징이나 OutOfMemoryError가 발생)
다 쓴 객체 참조(obsolere reference)를 여전히 가지고 있기 때문이다.
GC 언어에서 메모리 누수를 찾기 어려워하는 이유는 객체 참조 하나를 살려두면 가비지 컬렉터는 그 객체뿐아니라 그 객체가 참조하는 모든 객체를 회수해가지 못하기 때문이다.
다 쓴 참조를 null 처리하면 참조 해제가 된다. 그래서 모든 객체를 쓰자마자 null 처리하는데, 그럴 필요도 없고 바람직하지 않다. 객체 참조를 null처리하는 일은 예외적인 경우여야한다. 만약 null 처리한 참조를 실수로 사용하려 하면 프로그램은 즉시 NullPointerException이 발생되며 종료가 된다.
자기 메모리를 직접 관리하는 클래스라면 프로그래머는 항시 메모리 누수에 주의해야한다. 이런 경우 사용후 즉시 그 원소가 참조한 객체들을 다 null 처리해줘야한다.
캐시 역시 메모리 누수를 일으키는 주범이다. 캐시 외부에서 key를 참조하는 동안만 엔트리가 살아 있는 캐시가 필요한 상황이면 WeakHashMap을 사용해 캐시를 만든다. 그럼 다 쓴 엔트리는 자동으로 제거 될 것이다.
리스너 혹은 콜백도 메모리 누수의 주범이다. 클라이언트가 콜백을 등록만 하고 명확히 해지하지 않는다면, 콜백은 계속 쌓일 것이다. 이럴때 콜백을 약한 참조(weak reference)로 저장하면 가비지 컬렉터가 즉시 수거해간다.
아이템 8. finalizer와 cleaner 사용을 피하라
자바는 두 가지 객체 소멸자를 제공한다. 그중 finalizer는예측할 수 없고, 상황에 따라 위험할 수 있어 일반적으로 불필요하다.(오작동, 낮은 성능, 이식성문제의 원인이 되기도함)
자바 9부턴 finalizer 사용 자체 API로 지정하고 cleaner를 그 대안으로 소개했다. cleaner는 finalizer 보다는 덜 위험하지만, 여전히 예측할 수 없고, 느리고, 일반적으로 불필요하다.
자바의 finalizer와 cleaner는 C++의 소멸자와 다른 개념이다. C++에서의 소멸자는 특정 객체와 관련된 자원을 회수하는 보편적인 방법이다. 자바에서는 접근할 수 없게된 객체를 회수하는 역할을 가비지 컬렉터가 담당하고, 프로그래머에겐 아무런 작업을 요구하지 않는다. 즉, 즉시 실행된다는 보장이 없다. (제때 실행되어야하는 작업에서는 사용하지 말것)
상태를 영구적으로 수정하는 작업의 경우 finalizer와 cleaner의 사용을 의존해선 안된다.
이와 비슷한 것으로 System.gc 나 System.runFinaliztion 메서드가 있는데 finalizer와 cleaner가 실행될 가능성을 높여줄 수 있느나, 보장해주지 않는다.
finalizer 동작 중 발생한 예외는 무시되며, 처리할 작업이 남았더라도 그 순간 종료된다. (처리가 덜된 상태에서 종료될 수 있다)
finalizer와 cleaner는 심각한 성능문제도 동반한다. finalizer와 cleaner는 가비지 컬렉터가 객체를 바로 수거해가지 않기 때문에 성능에 영향을 준다
finalizer를 사용한 클래스는 finalizer 공격에 노출되어 심각한 보안 문제를 일으킬 수도 있다.
finalizer와 cleaner의 대안으로 AutoCloseable을 구현해주고 클라이언트에서 인스턴스를 다 쓰고 나면 close 메서드를 호출하면 된다.
finalizer와 cleaner의 적절한 예
자원의 소유자가 close메서드를 호출하지 않는 것에 대비한 안전망 역할
네이티비 피어와 연결된 객체를 해제할 때 사용한다. 네이티비 객체는 GC에서 알지 못한다. 단, 성능저하는 감수하고 사용해야한다.
아이템 9. try-finally 보다 try-with-resources 를 사용하라
전통적으로 자원이 제대로 닫힘을 보장하는 수단으로 try-finally가 쓰였다. 하지만 예외는 try 블록과 finally 블록 모두에서 발생할 수 있는데, 예컨데 기기에 물리적인 문제가 생긴다면 firstLineOfFile 메서드 안의 readLine 메서드가 실패할 것이다. 이런 상황이라면 두 번째 예외가 첫 번째 예외를 완전히 집어삼켜 버린다. 그러면 스택 추적 내역에 첫 번째 예외에 관한 정보는 남지 않게 되어, 실제 시스템에서 디버깅을 몹시 어렵게 한다.
하지만 try-with-resources로 앞선 문제가 해결되었다. 이 구조를 사용하려면 해당 자원이 AutoCloseable 인터페이스를 구현해야한다. 단순히 void를 반환하는 close 메서드 하남 덩그러니 정의한 인터페이스다.
try-with-resources는 짧고 읽기 수월할 뿐만이 아니라 문제를 진단하기도 훨씬 좋다. try-finally의 경우 예외가 숨겨져서 못 볼 수 있지만 try-with-resources는 숨겨진 예외들도 버려지지는 않고, 스택 추적 내역에 숨겨졌다는 꼬리표를 달고 출력된다. 또한 자바 7부터 Throwable에 추가된 getSuppressed 메서드를 이용하면 프로그램 코드에서 가져올 수 있다.
|
댓글
댓글 쓰기