객체를 만들어야 할 때와 만들지 말아야 할 떄를 구분하는 법, 올바른 객체 생성 방법과 불필요한 생성을 피하는 방법, 제때 파괴됨을 보장하고 파괴 전에 수행해야 할 정리 작업을 관리하는 요렁
item 1. 생성자 대신 정적 팩터리 메서드를 고려하라.
정적 팩터리 메서드와 public 생성자는 각자의 쓰임새가 있으니 상대적인 장단점을 이해하고 사용하는 것이 좋다.
그렇다고 하더라도 정적 팩터리를 사용하는 게 유리한 경우가 더 많으므로 무작정 public 생성자를 제공하던 습관이 있다면 고치자.
👍
장점 1.
생성자의 시그니처가 중복되는 경우 팩터리 메서드를 통해 표현이 가능하다.
팩터리 메서드를 통해 객체의 특징을 이름으로 더 자세하게 표현(반환될 객체의 특성을 쉽게 묘사) 가능하다.
public class Order {
private boolean prime;
private boolean urgent;
private Product product;
/* 생성자의 시그니처가 중복되는 경우 */
public Order(Product product, boolean prime) {
this.product = product;
this.prime = prime;
}
// 'Order(Product, boolean)' is already defined in 'Order'
public Order(Product product, boolean urgent) {
this.product = product;
this.urgent = urgent;
}
}
...
public class Order {
private boolean prime;
private boolean urgent;
private Product product;
/* 팩터리 메서드로 더 자세한 표현(객체의 특징) 가능 */
public static Order primeOrder(Product product) {
Order order = new Order();
order.prime = true;
order.product = product;
return order;
}
public static Order urgentOrder(Product product) {
Order order = new Order();
order.urgent = true;
order.product = product;
return order;
}
}
장점 2.
호출될 때마다 인스턴트를 새로 생성하지 않아도 된다.
불필요한 객체 생성을 피하여 성능을 올려줄 수 있음
인스턴스 통제 클래스(instance-controlled)
java.lang.Boolean.valueOf()
public static Boolean valueOf(boolean b) {
return b ? Boolean.TRUE : Boolean.FALSE;
}
public class Settings {
private boolean useAutoSteering;
private boolean useABS;
private Difficulty difficulty;
private Settings() {}
private static final Settings SETTINGS = new Settings();
/* 객체 생성을 자신이 컨트롤 */
public static Settings getInstance() {
return SETTINGS;
}
}
...
Settings settings1 = Settings.getInstance();
Settings settings2 = Settings.getInstance();
장점 3.
반환 타입의 하위 타입 객체를 반환할 수 있는 능력이 있다.
반환할 객체의 클래스를 자유롭게 선택할 수 있는 유연성 보유
인터페이스 기반 프레임워크를 만드는 핵심 기술
장점 4.
입력 매개변수에 따라 매번 다른 클래스의 객체를 반환할 수 있다.
클라이언트는 팩터리가 건네주는 객체가 어느 클래스의 인스턴스인지 알 수도 없고 알 필요도 없다.
java.util.EnumSet.noneOf()
public interface HelloService {
String hello();
/**
* 장점 3.
*
* @return HelloService interface
* 리턴 타입은 인터페이스지만 실제 리턴 인스턴스는 인터페이스의 구현체.
* 또는
* 리턴 타입은 클래스지만 실제 리턴 인스턴스는 하위 클래스.
*/
static HelloService of(String lang) {
/**
* 장점 4.
*
* 매개변수에 따라 각기 다른 인스턴스 제공
*/
if (lang.equals("ko")) {
return new KoreanHelloService();
} else {
return new EnglishHelloService();
}
}
}
...
// 인테스이스 기반 프레임워크를 사용하도록 강제하고, 구현체는 숨길 수 있음
HelloService ko = HelloServiceFactory.of("ko");
계층 구조에서 self() 메소드를 통해 형변환을 줄이고, 하위 빌더에 메서드를 추가할 수 있음
클라이언트는 필요한 객체를 직접 만드는 대신, 필수 매개변수만으로 생성자를 호출해 빌더 객체를 얻는다.
그 후 빌더 객체가 제공하는 일종의 세터 메서드들로 원하는 선택 매개변수들을 설정
빌더 패턴의 단점도 존재
빌더 생성 비용이 크지는 않지만 성능에 민감한 상황에서는 문제가 될 수 있음
점층적 생성자 패턴보다는 코드가 장황해서 매개변수 4개 이상은 되어야 값어치를 함
.
@Builder
장점.
애노테이션 하나로 간결하게 빌더 패턴을 구현
target.classes.. 에서 생성된 Builder 클래스 확인 가능
단점.
빌더뿐만 아니라 모든 매개변수를 파라미터로 받는 생성자 자동 생성
필수값 지정 불가(필수 값을 생성자에 넣어주고 싶을 경우 어려움)
@Builder
// 모든 매개변수를 파라미터로 받는 생성자를 외부에서 호출하지 못 하도록 AccessLevel 설정
@AllArgsConstructor(access = AccessLevel.PRIVATE)
public class NutritionFacts {
private final int servingSize;
private final int servings;
private final int calories;
//..
}
...
new NutritionFacts.NutritionFactsBuilder()
.servingSize(10)
.servings(10)
.build();
item 3. private 생성자나 열거 타입으로 싱글턴임을 보증하라.
만들려는 싱글턴이 Enum 이외의 클래스를 상속하지 않는다면, "원소가 하나인 열거 타입을 선언" 방식을 선택해 보자.
📖
싱클턴을 만드는 세 가지 방법
.
private 생성자 + public static final 필드 방식의 싱글턴
public class Elvis {
public static final Elvis INSTANCE = new Elvis();
private Elvis() { }
public void leaveTheBuilding() { ... }
public void sing() { ... }
}
...
Elvis elvis = Elvis.INSTANCE;
elvis.leaveTheBuilding();
장점.
public, protected 생성자가 없으므로 클래스 초기화 시 만들어진 인스턴스가 전체 시스템에서 하나뿐임을 보장
간결하고 해당 클래스가 싱글턴인 것이 API(javadocs)에 명백히 드러남
final 이므로 다른 객체 참조 불가
단점.
(인터페이스가 없다면) 싱글톤을 사용하는 클라이언트가 테스트하기 어려움
인터페이스를 생성해서 Mock 객체로 테스트 가능
리플렉션으로 private 생성자 호출 가능
생성자 두 번째 호출 시 인스턴스 생성 막는 방법 필요
// 선언 되어 있는 기본 생성자에 접근(접근 지시자에 상관 없이 접근 가능)
Constructor<Elvis> defaultConstructor = Elvis.class.getDeclaredConstructor();
defaultConstructor.setAccessible(true);
Elvis elvis1 = defaultConstructor.newInstance();
Elvis elvis2 = defaultConstructor.newInstance();
...
// 생성자 두 번째 호출 시 인스턴스 생성 막는 방법 필요
private static boolean created;
private Elvis() {
if (created) {
throw new UnsupportedOperationException("can't be created by constructor.");
}
created = true;
}
역직렬화 시 새로운 인스턴스가 생성될 수 있음
역직렬화 시 새로운 인스턴스가아닌 기존 인스턴스 리턴하도록 재정의
// 직렬화
try (ObjectOutput out = new ObjectOutputStream(new FileOutputStream("elvis.obj"))) {
out.writeObject(Elvis.INSTANCE);
} catch (IOException e) {
e.printStackTrace();
}
// 역직렬화
try (ObjectInput in = new ObjectInputStream(new FileInputStream("elvis.obj"))) {
Elvis elvis3 = (Elvis) in.readObject();
System.out.println(elvis3 == Elvis.INSTANCE);
} catch (IOException | ClassNotFoundException e) {
e.printStackTrace();
}
...
public class Elvis implements IElvis, Serializable {
//...
// 역직렬화 시 새로운 인스턴스가아닌 기존 인스턴스 리턴하도록 재정의
// 진짜 Elvis를 반환하고, 가짜 Elvis는 가비지 컬렉터에
private Object readResolve() {
return INSTANCE;
}
}
.
private 생성자 + 정적 팩터리 방식의 싱글턴
public class Elvis {
private static final Elvis INSTANCE = new Elvis();
private Elvis() { }
public static Elvis getInstance() { return INSTANCE; }
public void leaveTheBuilding() { ... }
}
..
Elvis elvis = Elvis.getInstance();
elvis.leaveTheBuilding();
장점
API 변경 없이 싱글턴이 아니도록 변경 가능
클라이언트 코드는 유지하면서 내부 코드 변경 가능
정적 팩터리를 제네릭 싱글턴 팩터리로 만들 수 있음
클라이언트가 원하는 타입을 사용할 수 있도록 지원
public class MetaElvis<T> {
private static final MetaElvis<Object> INSTANCE = new MetaElvis<>();
private MetaElvis() { }
@SuppressWarnings("unchecked")
public static <E> MetaElvis<E> getInstance() { return (MetaElvis<E>) INSTANCE; }
public void say(T t) { ... }
public void leaveTheBuilding() { ... }
public static void main(String[] args) {
MetaElvis<String> elvis1 = MetaElvis.getInstance();
MetaElvis<Integer> elvis2 = MetaElvis.getInstance();
elvis1.say("hello");
elvis2.say(100);
}
}
정적 팩터리의 메서드 참조를 공급자(Supplier<>)로 사용 가능
public class Concert {
public void start(Supplier<Singer> singerSupplier) {
Singer singer = singerSupplier.get();
singer.sing();
}
public static void main(String[] args) {
Concert concert = new Concert();
concert.start(Elvis::getInstance);
}
}
단점
private 생성자 + public static final 필드 방식의 싱글턴과 동일한 단점
.
원소가 하나인 열거 타입을 선언
public enum Elvis {
INSTANCE;
public void leaveTheBuilding() { ... }
}
..
Elvis elvis = Elvis.INSTANCE;
elvis.leaveTheBuilding();
가장 간결한 방법이고, 직렬화와 리플렉션에도 안전
아주 복잡한 직렬화 상황이나 리플렉션 공격에서도 제 2의 인스턴스가 생기는 일을 완벽하게 방어
enum 은 리플렉션 내부 코드에서 생성자를 가져올 수 없도록 설정
new 키워드로 enum 을 생성할 수 없는 특성을 반영
대부분 상황에서 원소가 하나뿐인 열거 타입이 싱글턴을 만드는 가장 좋은 방법
단, 만들려는 싱글턴이 Enum 이외의 클래스를 상속해야 한다면 이 방법은 사용 불가
item 4. 인스턴스화를 막으려거든 private 생성자를 사용하라.
public class UtilityClass {
/**
* 이 클래스는 인스턴스를 만들 수 없습니다.
* 기본 생성자가 만들어지는 것을 방지(인스턴스화 방지로 상속 불가능)
*/
private UtilityClass() {
throw new AssertionError();
}
// ...
}
추상(abstract) 클래스로 만드는 것으로는 인스턴스화를 막을 수 없다
기본 생성자가 자동으로 생성
상속받은 자식 클래스의 인스턴스 생성 시 상위 클래스의 생성자를 자동으로 호출하는 자바 특성
컴파일러가 기본 생성자를 만드는 경우는 오직 명시된 생성자가 없을 때뿐이니 private 생성자를 추가하면 클래스의 인스턴스화를 막을 수 있다.
생성자에 주석으로 인스턴스화 불가한 이유를 설명하는 것이 좋다
상속을 방지할 때도 같은 방법을 사용할 수 있다
ex. 인스턴스를 만들 수 없는 유틸리스 클래스
정적(static) 메서드만 담은 유틸리티 클래스는 인스턴스로 만들어 쓰려고 설계한 클래스가 아님
item 5. 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라.
클래스가 내부적으로 하나 이상의 자원에 의존하고, 그 자원이 클래스 동작에 영향을 준다면 싱글턴과 정적 유틸리티 클래스는 사용하지 않는 것이 좋다.
이 자원들을 클래스가 직접 만들게 해서도 안 된다.
대신 필요한 자원을(혹은 그 자원을 만들어주는 팩터리를) 생성자에(혹은 정적 팩터리나 빌더에) 넘겨주자.
의존 객체 주입이라 하는 이 기법은 클래스와의 유연성, 재사용성, 테스트 용이성을 기막히게 개선해준다.
📖
// 자원을 직접 명시하지 말고
private static final Dictionary dictionary = new Dictionary();
...
// 의존 객체 주입 사용
public class SpellChecker {
// Dictionary interface 를 주입받아서 코드의 재사용성을 높일 수 있음
private final Dictionary dictionary;
// 생성자에 필요한 자원을 넘겨준다.
public SpellChecker(Dictionary dictionary) {
this.dictionary = Object.requireNonNull(dictionary);
}
public boolean isValid(String word) { ... }
public List<String> suggestions(String typo) { ... }
}
사용하는 자원에 따라 동작이 달라지는 클래스에는 정적 유틸리티 클래스나 싱글턴 방식이 비적합
대신 클래스가 여러 자원 인스턴스를 지원해야 하며, 클라이언트가 원하는 자원을 사용해야 한다.
의존 객체 주입 패턴: 인스턴스를 생성할 때 생성자에 필요한 자원을 넘겨주는 방식
변형 방식으로 생성자에 자원 팩터리를 넘겨줄 수 있음
의존 객체 주입 통해 클래스의 유연성, 재사용성, 테스트 용이성 개선 가능
의존 객체 주입 프레임워크(Dagger, Guice, Spring)를 사용하면 큰 프로젝트에서 코드가 어지러워지는 단점 개선 가능
item 6. 불필요한 객체 생성을 피하라.
문자열
/**
* 불필요한 객체 생성으로 인한 메모리 낭비 개선
*/
String hello = "hello"; // JVM은 내부적으로 문자열을 pool에 캐싱
String hello2 = new String("hello"); // 강제로 새로운 문자열 생성
new String("str")을 사용하지 않고, 문자열 리터럴("str)을 재사용하는 것을 권장
문자열 리터럴은 사실상 동일한 객체라서 매번 새로 만들 필요가 없음
똑같은 기능의 객체를 매번 생성하기보다 객체 하나를 재사용하는 편이 나을 때가 많음
생성자 대신 정적 팩터리 메서드를 제공하는 불변 클래스에서는 정적 팩터리 메서드를 사용해 불필요한 객체 생성을 피할 수 있음
생성자는 호출할 때마다 새로운 객체를 만들지만, 팩터리 메서드는 그렇지 않다.
ex. Boolean.valueOf(String)
정규식 Pattern
/**
* 값비싼 객체를 재사용해 성능을 개선
*/
public class RomanNumerals {
private static final Pattern ROMAN = Pattern.compile(
"^(?=.)M*(C[MD]|D?C{0,3})"
+ "(X[CL]|L?X{0,3})(I[XV]|V?I{0,3})$");
static boolean isRomanNumeralFast(String s) {
return ROMAN.matcher(s).matches();
}
}
생성 비용(CPU 리소스)이 비싼 객체라서 반복해서 생성하기 보다, 캐싱하여 재사용하는 것을 권장
동일한 패턴이 여러번 사용된다면 필드로 선언해서 사용 권장
오토박싱(Auto Boxing)
/**
* 불필요한 객체 생성으로 인한 메모리 낭비 개선
*/
private static long sum() {
Long sum = 0L; // Long으로 선언해서 불필요한 인스턴스가 약 2^31개나 생성
for (long i = 0; i <= Integer.MAX_VALUE; i++)
sum += i;
return sum;
}
기본 타입(int)을 그에 상응하는 박싱된 기본 타입(Integer)으로 상호 변환해주는 기술
기본 타입과 박싱된 기본 타입을 섞어서 사용하면 변환하는 과정에서 불필요한 객체가 생성될 수 있음
박싱된 기본 타입보다는 기본 타입을 사용하고, 의도치 않은 오토박싱이 숨어들지 않도록 주의하자
item 7. 다 쓴 객체 참조를 해제하라.
메모리 누수는 겉으로 잘 드러나지 않아 시스템에 수년간 잠복하는 사례도 있다.
이런 누수는 철저한 코드 리뷰나 힙 프로파일러 같은 디버깅 도구를 동원해야만 발견되기도 한다.
그래서 이런 종류의 문제는 예방법을 익혀두는 것이 매우 중요하다.
📖
CG(가비지 컬렉션) 언어에서는 메모리 누수를 찾기가 아주 까다로움
메모리 누수로 단 몇 개의 객체가 매우 많은 객체를 회수되지 못하게 할 수 있고, 잠재적으로 성능에 악영향을 줄 수 있음
어떤 객체에 대한 레퍼런스가 남아있다면 해당 객체는 가비지 컬렉션의 대상이 되지 않음
해법은 해당 참조를 다 썻을 때 참조 해제(null 처리)하기
참조 해제의 가장 좋은 방법은 그 참조를 담은 변수를 유효 범위 밖으로 밀어내는 것
자기 메모리를 직접 관리하는 클래스(Stack, Cache, Listener/Callback)라면 항시 메모리 누수에 주의
.
참조 해제 방법
(1) 해당 참조를 다 사용했을 경우 null 처리
public Object pop() {
if (size == 0) {
throw new EmptyStackException();
}
Object result = elements[--size];
elements[size] = null; // 다 쓴 참조 해제
return result;
}
(2) WeakHashMap 자료구조
약한 참조로 저장(WeakHashMap애 Key로 저장) 시 가비지 컬렉터가 즉시 수거
public class PostRepository {
private Map<CacheKey, Post> cache;
public PostRepository() {
this.cache = new WeakHashMap<>();
}
public Post getPostById(CacheKey key) {
if (cache.containsKey(key)) {
return cache.get(key);
} else {
// DB, REST API를 통한 조회
Post post = new Post();
cache.put(key, post);
return post;
}
}
//...
}
...
PostRepository postRepository = new PostRepository();
CacheKey key1 = new CacheKey(1);
postRepository.getPostById(key1);
assertFalse(postRepository.getCache().isEmpty());
key1 = null;
// WeakHashMap Key 는 GC가 즉시 수거
System.out.println("run gc");
System.gc();
System.out.println("wait");
Thread.sleep(3000L);
assertTrue(postRepository.getCache().isEmpty());
(3) Background Threads & LRU Cache
LRU(Least Recently Used) cache
가장 오랫동안 사용되지 않은 캐시 제거
ScheduledExecutorService executor = Executors.newScheduledThreadPool(1);
PostRepository postRepository = new PostRepository();
CacheKey key1 = new CacheKey(1);
postRepository.getPostById(key1);
// 백그라운드 스레드에서 가장 오랫동안 사용되지 않은 캐시 제거
Runnable removeOldCache = () -> {
System.out.println("running removeOldCache task");
Map<CacheKey, Post> cache = postRepository.getCache();
Set<CacheKey> cacheKeys = cache.keySet();
Optional<CacheKey> key = cacheKeys.stream().min(Comparator.comparing(CacheKey::getCreated));
key.ifPresent((k) -> {
System.out.println("removing " + k);
cache.remove(k);
});
};
// 처음에 1초 있다가 3초마다 러너 실행
executor.scheduleAtFixedRate(removeOldCache, 1, 3, TimeUnit.SECONDS);
// 20초동안 애플리케이션을 돌리는 동안 별도의 스레드기 수행
Thread.sleep(20000L);
executor.shutdown();
item 8. finalizer와 cleaner 사용을 피하라.
cleaner(java8 까지는 finalizer)는 안전망 역할이나 중요하지 않은 네이티브 자원 회수용으로만 사용하자.
물론 이런 경우라도 불확실성과 성능 저하에 주의해야 한다.
📖
자바는 두 가지 객체 소멸자(finalizer, cleaner)를 제공
finalizer는 예측할 수 없고, 상황에 따라 위험할 수 있어 일반적으로 불필요
cleaner는 finalizer보다는 덜 위험하지만, 여전히 예측할 수 없고, 느리고, 일반적으로 불필요
finalizer와 cleaner로는 제때 수행되어야 하는 작업은 절대 할 수 없음
즉시 수행된다는 보장이 없고, GC 알고리즘에 달려있어 GC 구현마다 천차만별
상태를 영구적으로 수정하는 작업에서는 절대 finalizer, cleaner에 의존하지 말자
finalizer와 cleaner는 심각한 성능 문제도 동반
finalizer를 사용한 클래스는 finalizer 공격에 노출되어 심각한 보안 문제를 일으킬 수도 있음
final이 아닌 클래스를 finalizer 공격으로부터 방어하려면 아무 일도 하지 않는 finalize 메서드를 만들고 final로 선언하기
.
반납할 자원이 있는 클래스는 AutoCloseable을 구현하고, 클라이언트에서 close()를 호출하거나 try-with-resource를 사용하도록 하자.
public class AutoClosableIsGood implements Closeable {
private BufferedReader reader;
//...
@Override
public void close() {
try {
reader.close();
} catch (IOException e) {
throw new RuntimeException(e);
}
}
}
...
try (AutoClosableIsGood good = new AutoClosableIsGood()) {
//...
}
.
cleaner 와 finalizer 의 사용
(1). 자원의 소유자가 close 메서드를 호출하지 않는 것에 대비한 안전망 역할
PhantomReference 사용
호출되리라는 보장이 없지만 없는 것 보다는 나을 수 있음
(2). Native peer 와 연결된 객체에서 자원을 즉시 회수해야 한다면 close 메서드를 사용
// 입력 타입은 반드시 Object (다중정의)
@Override public boolean equals(Object o) {
// 1. 반사성을 만족(필드들의 동치성만 검사해도 equals 규약을 어렵지 않게 지킬 수 있음)
if (o == this) return true;
// 2. 타입 비교
if (!(o instanceof PhoneNumber)) return false;
// 3. 타입 변환
PhoneNumber pn = (PhoneNumber)o;
// 4. 핵심 필드 비교
return pn.lineNum == lineNum
&& pn.prefix == prefix
&& pn.areaCode == areaCode;
}
Float.compare()와 Double.compare()을 제외한 기본 타입 필드는 == 연산자로 비교
참조 타입 필드는 각각의 equals 메서드로 비교
배열 필드는 원소 각각을 앞서의 지침대로 비교하고, 모든 원소가 핵심 필드라면 Arrays.equals 메서드들 중 하나를 사용
null 가능성이 있을 경우 Objects.equals(Object, Object) 비교로 NPE 방지
/**
* lombok @EqualsAndHashCode
* - 사용 편의성 관점에서 권장하는 방법
* - 이미 테스트를 거친 상태이므로 테스트 불필요
*/
@EqualsAndHashCode
public class PhoneNumber {
}
/**
* IDE 에서 제공해 주는 hashCode 메서드
* - Objects 클래스의 hash 메서드
*/
@Override public int hashCode() {
return Objects.hash(lineNum, prefix, areaCode);
}
/**
* 전형적인 hashCode 메서드
* - 사전의 모든 단어에 31 을 사용했을 때, 해시 충돌이 가장 적었다는 연구 결과를 반영
*/
@Override public int hashCode() {
int result = Short.hashCode(areaCode); // 핵심 필드 하나의 해쉬값 계산
result = 31 * result + Short.hashCode(prefix);
result = 31 * result + Short.hashCode(lineNum);
return result;
}
/**
* 구글 구아바의 com.google.common.hash.Hashing
* - 좋은 성능을 가지고 있지만 hashCode 구현을 위해 라이브러리 추가 필요
* - https://mvnrepository.com/artifact/com.google.guava/guava
*/
@Override public int hashCode() {
return Hashing.goodFastHash(32)
.hashObject(this, PhoneNumberFunnel.INSTANCE)
.hashCode();
}
/**
* 해시코드를 지연 초기화하는 hashCode 메서드
* - 스레드 안정성을 위해 Double Checked Locking 기법 적용
* - volatile field: Thread-safety 한 변수
* - 보통 변수를 CPU cache 에 저장해서 예전 캐시 값을 읽어올 수도 있지만,
* - volatile 는 변수를 Main Memory 에 저장해서 가장 최근에 업데이터된 데이터를 참조
*/
private volatile int hashCode;
@Override public int hashCode() {
// First check outside synchronized
if (this.hashCode != 0) {
return hashCode;
}
synchronized (this) {
int result = hashCode;
// Second check in synchronized
if (result == 0) {
result = Short.hashCode(areaCode);
result = 31 * result + Short.hashCode(prefix);
result = 31 * result + Short.hashCode(lineNum);
this.hashCode = result;
}
return result;
}
}
모든 구체 클래스에서 Object의 toString을 재정의하자(상위 클래스에서 이미 알맞게 재정의한 경우는 예외)
toString을 재정의한 클래스는 사용하기도 즐겁고, 그 클래스를 사용한 시스템을 디버깅하기 쉽게 해준다.
toString은 해당 객체에 관한 명확하고 유용한 정보를 간결하고 읽기 좋은 형태로 반환해야 한다.
📖
Object의 toString은 클래스이름@16진수로 표시한 해시 코드
객체가 가진 보여줄 수 있는 모든 정보를 보여주는 것이 좋다.
값 클래스라면 포맷을 문서에 명시하는 것이 좋으며, 해당 포맷으로 객체를 생성할 수 있는 정적 팩터리나 생성자를 제공하는 것이 좋다.
toString이 반환한 값에 포함된 정보를 얻어올 수 있는 API(Getter)를 제공하는 것이 좋다.
경우에 따라 AutoValue, 롬복 또는 IDE를 사용하지 않는게 적절할 수 있다.
ex. 전화번호, 주소, 좌표, 위도, 경도 등 특정 포맷이 정해져있는 경우
📝 포맷을 명시한 경우
public final class PhoneNumber {
//..
/**
* 이 전화번호의 문자열 표현을 반환한다.
* 이 문자열은 "XXX-YYY-ZZZZ" 형태의 12글자로 구성된다.
* XXX는 지역 코드, YYY는 프리픽스, ZZZZ는 가입자 번호다.
* 각각의 대문자는 10진수 숫자 하나를 나타낸다.
*
* 전화번호의 각 부분의 값이 너무 작아서 자릿수를 채울 수 없다면,
* 앞에서부터 0으로 채워나간다. 예컨대 가입자 번호가 123이라면
* 전화번호의 마지막 네 문자는 "0123"이 된다.
*/
@Override public String toString() {
return String.format("%03d-%03d-%04d", areaCode, prefix, lineNum);
}
// 특정 포맷으로 객체를 생성할 수 있는 정적 팩터리나 생성자
public static PhoneNumber of(String phoneNumberString) {
String[] split = phoneNumberString.split("-");
PhoneNumber phoneNumber = new PhoneNumber(
Short.parseShort(split[0]),
Short.parseShort(split[1]),
Short.parseShort(split[2]));
return phoneNumber;
}
}
item 13. clone 재정의는 주의해서 진행하라.
Cloneable이 몰고 온 모든 문제를 되짚어봤을 때, 새로운 인터페이스를 만들 때는 절대 Cloneable을 확장해서는 안 되며, 새로운 클래스도 이를 구현해서는 안 된다.
final 클래스라면 Cloneable을 구현해도 위험이 크지 않지만, 성능 최적화 관점에서 검토한 후 별다른 문제가 없을 때만 드물게 혀용해야 한다.
기본 원칙은 '복제 기능은 생성자와 팩터리를 이용하는 게 최고!' 라는 것.
단, 배열만은 clone 메서드 방식이 가장 깔끔한, 이 규칙의 합당한 예외라고 할 수 있다.
📖
Cloneable을 구현한 클래스는 clone 메서드를 public으로 제공
사용자는 당연히 복제가 제대로 이뤄지리라 기대하지만, 깨지기 쉽고, 위험하고, 모순적인 매커니즘이 탄생..
.
clone 규약
x.clone() != x (clone은 원본과 다른 인스턴스)
x.clone().getClass() == x.getClass()
x.clone().equals(x) true가 아닐 수 있음 (객체마다 고유 식별자가 있을 경우)
.
📝 불변 상태를 참조하는 클래스용 clone 메서드
public final class PhoneNumber implements Cloneable {
// ...
@Override public PhoneNumber clone() {
try {
// 재정의한 메서드의 반환 타입은 상위 클래스의 메서드가 반환하는 타입의 하위 타입일 수 있다.
return (PhoneNumber) super.clone();
} catch (CloneNotSupportedException e) {
// checkedException → UncheckedException 변환
throw new AssertionError();
}
}
}
불변 객체라면 Cloenable 인터페이스를 구현하고, super.clone()를 사용해서 clone 메서드를 재정의하면 충분
접근 제한자는 public, 반환 타입은 자신의 클래스로 변경
Cloenable 인터페이스를 구현하지 않으면 CloneNotSupportedException 발생
clone 메서드는 사실상 생성자와 같은 효과
clone은 원본 객체에 아무런 해를 끼치지 않는 동시에 복제된 객체의 불변식을 보장해야 한다.
하지만, 정말 생성자를 사용하여 만든 객체를 반환하면 규약이 깨지게 된다.
하위 타입이 상위 타입을 받을 수 없는 cannot be cast to class 예외 발생
.
📝 가변 상태를 참조하는 클래스용 clone 메서드
public class Stack implements Cloneable {
private Object[] elements;
private int size = 0;
//...
@Override public Stack clone() {
try {
Stack result = (Stack) super.clone();
// elements 필드가 복사본과 같은 메모리를 참조하지 않도록 배열의 clone을 재귀적으로 호출
// 배열은 깊은 복사를 해주지 않으면 원본, 복사본 두 인스턴스가 동일한 배열을 참조
result.elements = elements.clone();
return result;
} catch (CloneNotSupportedException e) {
throw new AssertionError();
}
}
}
불변 상태를 참조하는 클래스용 clone 메서드와 기본적으로 동일
추가로, super.clone() 호출 후 필요한 필드를 적절히 수정
배열 복제 시 배열의 clone 메서드 사용, 필요 시 deep copy
public 고수준 메서드(get, put)를 호출하는 방법 존재
clone 메서드 내에서 하위 클래스가 재정의할 수 있는 메서드는 사용하지 않기
사용해야 한다면 재정의 불가능하도록 final 선언
상속용 클래스(abstract class)는 Cloneable을 구현하지 않기
Cloneable을 구현한 스레드 안전 클래스를 작성할 때는 clone 메서드에 synchronized 선언으로 동기화
단점
모호한 규약
필드에 final 사용 불가(clone 과정에서 필드 값 할당이 필요)
생성자를 사용하지 않다보니 생성자에 있는 필드 검증 작업을 거치지 않음
형변환 필요
.
복사 생성자와 복사 팩터리를 사용한 복사를 권장
문서화된 규약에 기대지 않고, 정상적인 final 필드 용법과 충돌하지 않고, 불필요한 검사 예외를 던지지 않고, 형변환도 필요하지 않음
해당 클래스가 구현한 interface 타입의 인스턴스를 인수로 받을 수 있음
클라이언트는 원본의 구현 타입에 얽매이지 않고 복제본의 타입을 직접 결정 가능
public TreeSet(Comparator<? super E> comparator) {
this(new TreeMap<>(comparator));
}
...
TreeSet<PhoneNumber> numbers = new TreeSet<>(Comparator.comparingInt(PhoneNumber::hashCode));
📝 복사 생성자 (변환 생성자, conversion constructor)
// 자신과 같은 클래스의 인스턴스를 인수로 받는 생성자
public PhoneNumber(PhoneNumber phoneNumber) {
this(phoneNumber.areaCode, phoneNumber.prefix, phoneNumber.lineNum);
}
📝 복사 팩터리 (변환 팩터리, conversion factory)
// 복사 생성자를 모방한 정적 팩터리
public static PhoneNumber newInstance(PhoneNumber phoneNumber) {
return new PhoneNumber(phoneNumber.areaCode, phoneNumber.prefix, phoneNumber.lineNum);
}
item 14. Comparable을 구현할지 고려하라.
순서를 고려해야 하는 값 클래스를 작성한다면 반드시 Compareable 인터페이스를 구현하여,
그 인스턴스들을 쉽게 정렬하고, 검색하고, 비교 기능을 제공하는 컬렉션과 어우러지도록 하자.
compareTo 메서드에서 필드의 값을 비교할 때, < 와 > 연산자는 쓰지 말자.
그 대신 박싱된 기본 타입 클래스가 제공하는 정적 compare 메서드나
Comarator 인터페이스가 제공하는 비교자 생성 메서드를 사용하자.
📖
알파벳, 숫자, 연대 같이 순서가 명확한 값 클래스를 작성한다면 반드시 Comparable 인터페이스를 구현하자.
Compareable 구현으로 수많은 제네릭 알고리즘과 컬렉션의 힘을 누릴 수 있다.
public interface Comparable<T> {
int compareTo(T t);
}
.
compareTo 규약은 equals 규약과 유사
단순 동치성 비교(Object.equals)에 더해 순서 비교가 가능하며 Generic 지원
반드시 따라야 하는 것은 아니지만 x.compareTo(y) == 0 이라면 x.equals(y) == true
BigDecimal oneZero = new BigDecimal("1.0");
BigDecimal oneZeroZero = new BigDecimal("1.00");
System.out.println(oneZero.compareTo(oneZeroZero)); // 0(Tree, TreeMap)
System.out.println(oneZero.equals(oneZeroZero)); // false(순서가 없는 콜렉션)
compareTo 규약을 지키지 못하면 비교를 활용하는 클래스와 어울리지 못함
.
compareTo 구현 방법 (Compratable 구현)
(1) 자연적인 순서를 제공할 클래스에 implements Compratable 선언
(2) compareTo 메서드를 재정의
(3) comprareTo 메서드 안에서 기본 타입은 박싱된 기본 타입의 compare을 사용해 비교
(4) 핵심 필드가 여러 개라면 비교 순서가 중요
순서를 결정하는데 있어서 가장 중요한 필드를 비교하고, 그 값이 0이라면 다음 필드를 비교
// (1) 자연적인 순서를 제공할 클래스에 implements Compratable<T> 선언
public final class PhoneNumber implements Comparable<PhoneNumber> {
private final short areaCode, prefix, lineNum;
//...
// (2) compareTo 메서드를 재정의
@Override
public int compareTo(PhoneNumber pn) {
// (3) comprareTo 메서드 안에서 기본 타입은 박싱된 기본 타입의 compare을 사용해 비교
int result = Short.compare(areaCode, pn.areaCode);
// (4) 핵심 필드가 여러 개라면 비교 순서가 중요
if (result == 0) {
result = Short.compare(prefix, pn.prefix);
if (result == 0)
result = Short.compare(lineNum, pn.lineNum);
}
return result;
}
기존 클래스를 확장하고 필드를 추가하는 경우 compareTo 규약을 지킬 수 없음
자식 클래스에서 Compratable 구현 불가
이 경우, Composition 활용
public class NamedPoint implements Comparable<NamedPoint> {
private final Point point;
private final String name;
// ...
@Override
public int compareTo(NamedPoint namedPoint) {
// Point 비교는 Point 클래스에서 재정의한 compareTo 사용
int result = this.point.compareTo(namedPoint.point);
if (result == 0) {
result = this.name.compareTo(namedPoint.name);
}
return result;
}
}
...
public class Point implements Comparable<Point>{
// ...
@Override
public int compareTo(Point point) {
int result = Integer.compare(this.x, point.x);
if (result == 0) {
result = Integer.compare(this.y, point.y);
}
return result;
}
}
.
compareTo 구현 방법 (Comprator 구현)
자바 8부터 함수형 인터페이스, 람다, 메서드 레퍼런스와 Comprator가 제공하는 기본 메서드, static 메서드를 사용해서 Comprator 구현 가능
자바의 정적 임포트 기능을 이용하면 정적 비교자 생성 메서드들을 그 이름만으로 사용할 수 있어 코드가 간결
Comparator가 제공하는 메서드 사용하는 방법
(1) Comparator의 static 메서드를 사용해서 Comparator 인스턴스 만들기
(2) 인스턴스를 만들었다면 default 메서드를 사용해서 메서드 호출(체이닝) 이어가기
static, default 메소드의 매개변수로는 람다 표현식 또는 메서드 레퍼런스 사용 가능
// (1) Comparator가 제공하는 static 메서드를 사용하여 Comparator 인스턴스 생성
private static final Comparator<PhoneNumber> COMPARATOR =
comparingInt((PhoneNumber pn) -> pn.areaCode)
// (2) 인스턴스를 만들었다면 default 메서드를 사용해서 메서드 호출(체이닝) 이어가기
.thenComparingInt(pn -> pn.prefix)
// static, default 메소드의 매개변수로는 람다 표현식 또는 메서드 레퍼런스 사용 가능
.thenComparingInt(PhoneNumber::getLineNum);
@Override
public int compareTo(PhoneNumber pn) {
return COMPARATOR.compare(this, pn);
}
...
@FunctionalInterface
public interface Comparator<T> {
// ...
default Comparator<T> thenComparingInt(ToIntFunction<? super T> keyExtractor) {
return thenComparing(comparingInt(keyExtractor));
}
}
자주 변하는 속성(외적인 속성, extrinsti)과 변하지 않는 속성(내적인 속성, intrinsit)을 분리하고 재사용하여 메모리 사용을 줄일 수 있음
public class Character {
private char value;
private String color;
private Font font;
}
...
public class FontFactory {
// Factory 클래스에 자주 사용하는 알고리즘을 캐싱
private Map<String, Font> cache = new HashMap<>();
public Font getFont(String font) {
if (cache.containsKey(font)) {
return cache.get(font);
} else {
String[] split = font.split(":");
Font newFont = new Font(split[0], Integer.paserInt(sptli[1]));
cache.put(font, newFont);
return newFont;
}
}
}
.
Java8 Interface / Item 01
자바 8부터는 인터페이스가 정적 메서드를 가질 수 없다는 제한이 풀렸기 때문에 인스턴스화 불가 동반 클래스를 둘 이유가 별로 없다.
빌더를 사용하면 (빌더의 각 메소드에 나눠서) 가변인수(varargs) 매개변수를 여러 개 사용할 수 있다.
public void printNumbers(int... numbers) {
System.out.println(numbers.getClass().getCanonicalName()); // int[]
System.out.println(numbers.getClass().getComponentType()); // int
Arrays.stream(numbers).forEach(System.out::println);
}
여러 인자를 받을 수 있는 가변적인 Argument (Var+args)
메소드에 오직 하나만 선언 가능
메소드의 가장 마지막 매개변수가 되어야 함
.
메서드 참조 / Item 03
메소드 하나만 호출하는 람다 표현식을 줄여쓰는 방법
// 익명 내부클래스 적용
people.sort(new Comparator<Person>() {
@Override
public int compare(Person a, Person b) {
return a.birthday.compareTo(b.birthday);
}
});
...
// 람다 표현식 적용
people.sort((a, b) -> a.birthday.compareTo(b.birthday));
스태틱 메소드 레퍼런스
public static int compareByAge(Person a, Person b) {
return a.birthday.compareTo(b.birthday);
}
people.sort(Person::compareByAge);
인스턴스 메소드 레퍼런스
public int compareByAge(Person a, Person b) {
return a.birthday.compareTo(b.birthday);
}
Person person = new Person();
people.sort(person::compareByAge);
임의 객체의 인스턴스 메소드 레퍼런스
첫 번째 인자를 자기 자신으로 인식(Person a 생략 가능)
public int compareByAge(Person b) {
return this.birthday.compareTo(b.birthday);
}
people.sort(Person::compareByAge);
public class SpellChecker {
private final Dictionary dictionary;
// 생성자에 자원 팩터리를 전달
// 한정적 와일드카드 타입을 사용해 팩터리의 타입 매개변수를 제한
public SpellChecker(Supplier<? extends Dictionary> dictionarySupplier) {
this.dictionary = dictionarySupplier.get();
}
//..
}
...
public class DictionaryFactory {
public static DefaultDictionary get() {
// Dictionary 구현체
return new DefaultDictionary();
}
}
...
SpellChecker spellChecker = new SpellChecker(DefaultDictionary::get);
.
팩터리 메소드 패턴 / Item 05
public class SpellChecker {
private Dictionary dictionary; // Dictionary Interface
public SpellChecker(DictionaryFactory dictionaryFactory) {
// 새로운 Product를 제공하는 팩토리(TempDictionaryFactory)를 추가해도
// 팩토리를 사용하는 클라이언트 코드는 변경할 필요가 없음
this.dictionary = dictionaryFactory.getDictionary();
}
//..
}
...
public interface DictionaryFactory {
Dictionary getDictionary();
}
...
public class DefaultDictionaryFactory implements DictionaryFactory {
// 구체적으로 어떤 인스턴스를 만들지는 서브 클래스가 결정
@Override
public Dictionary getDictionary() {
return new DefaultDictionary();
}
}
개방-폐쇄 원칙(Open-Closed Principle, OCP)
확장에 대해 열려 있고, 변경에 대해 닫혀있는 구조
Spring IOC 핵심인 Bean Factory가 대표전인 팩터리 메소드 패턴
.
Spring Ioc / Item 05
BeanFactory 또는 ApplicationContext
Ioc(Inversion of Control): 뒤짚힌 제어권
코드에 대한 제어권(인스턴스 생성, 메소드 실행, 의존성을 주입 등)을 자기 자신이 가지고 있지 않고 외부에서 제어하는 경우
