[이펙티브 자바] 아이템 26. 로 타입은 사용하지 말라.

[tonykang22]

아이템 26. 로 타입은 사용하지 말라.

핵심 정리: 용어 정리

• 로 타입: List
• 제네릭 타입: List<E>
• 매개변수화 타입: List<String>
• 타입 매개변수: E
• 실제 타입 매개변수: String
• 한정적 타입 매개변수: List<E extends Number>
• 비한정적 와일드카드 타입: Class<?>
• 한정적 와일드카드 타입: Class<? extends Annotation>

핵심 정리

매개변수화 타입을 사용해야 하는 이유

• 런타임이 아닌 컴파일 타임에 문제를 찾을 수 있다. (안정성)
• 제네릭을 활용하면 이 정보가 주석이 아닌 타입 선언 자체에 녹아든다. (표현력)
  • 로 타입을 사용하면 안정성과 표현력을 잃는다.
• 그렇다면 자바는 왜 로 타입을 지원하는가?
  • 제네릭이 나온 자바 5 이하의 코드도 호환되도록 하기 위함이다.
• List와 List<Object>의 차이는?
  • List를 사용하면 타입 세이프하지 않다.
  • List는 무엇이나 받을 수 있지만, List<Object>는 무엇이나 받을 수 없다.
• Set과 Set<?>의 차이는?
  • List와 마찬가지로, 타입 세이프하지 않다.
  • Set<?>: 어떤 타입이어도 담을 수 있는 가장 범용적인 매개변수화 Set 타입이다.
  • 로 타입은 아무 값이나 추가할 수 있으나, 비한정적 와일드카드 사용 시에는 아무 값도 추가할 수 없다.
• 예외: class 리터럴과 instanceof 연산자
  • 컴파일 했을 때는 로 타입 뿐이다. (instatnceof 도 마찬가지이다.)
    • 컴파일 시 소거된다.
    • instanceof 에는 사용은 할 수 있지만, 어차피 소거되기에 괜히 코드만 장황하게 만드는 셈이다.

예시

컴파일 타임에 문제를 찾을 수 있다.

• Generic을 사용하기 전에는 컴파일 타임에 문제를 찾을 수 없었으나, 사용 후에는 컴파일 타임에 문제를 찾을 수 있다.

public class GenericBasic {

    public static void main(String[] args) {
//         Generic 사용하기 전
        List numbers = new ArrayList();
        numbers.add(10);
        numbers.add("tony");

//         로 타입 사용 시, Object / 형변환도 필요
        for (Object number: numbers) {
            System.out.println((Integer)number);
        }

//         Generic 등장 이후
        List<Integer> nuberms = new ArrayList<>();
        nuberms.add(10);
//         컴파일 에러
        nuberms.add("tony");

//         제네릭 사용 시, 지정한 타입 / 형변환 불필요
        for (Integer number: nuberms) {
            System.out.println(number);
        }
    }
}

제네릭 클래스

• 제네릭 클래스 Box 를 사용하면, 아래와 같이 코드의 중복을 방지할 수도 있다.
  • Integer 용 Box, String 용 Box 등을 매번 만들지 않아도 되기 때문이다.
• 한정적 타입 매개변수를 사용하는 예로는
  • Box<E extends Number> 등이 존재할 수 있다.
    • Box<String> 으로는 선언할 수 없다. : 컴파일 에러
  • 비한정적 와일드타입 매개변수: Box<?>
    • 아무런 타입이나 가능하다는 의미이다.
• Box<Object>를 매개변수로 사용하는 메서드에 Box<Integer>를 인자로 넘겨줄 수 없다.
  • 비한정적 와일드타입을 사용할 수 있는 부분
  • Box<Object>(컴파일 에러) → Box<? extends Object>(생략 가능) → Box<?>

public class Box<E> {

    private E item;

    private void add(E e) {
        this.item = e;
    }

    private E get() {
        return this.item;
    }

    public static void main(String[] args) {
        Box<Integer> box = new Box<>();
        box.add(10);
        System.out.println(box.get() * 100);

        printBox(box);
    }

    private static void printBox(Box<?> box) {
        System.out.println(box.get());
    }

}

자바는 왜 로 타입을 지원하는가?

• 하위 버전(자바 5 이하) 호환성을 위함이다.
• 컴파일된 코드는 전부 다 로 타입으로 보인다.
• 자바 코드로 편하게 제네릭을 사용하면, 타입 캐스팅까지 내부적으로 처리하는 것 뿐이다.

public class Box<E> {

    private E item;

    private void add(E e) {
        this.item = e;
    }

    private E get() {
        return this.item;
    }

    public static void main(String[] args) {
        Box<Integer> box = new Box<>();
        box.add(10);
        System.out.println(box.get() * 100);

        printBox(box);
    }

    private static void printBox(Box<?> box) {
        System.out.println(box.get());
    }

}

[tonykang22]

완벽 공략

• p 156, 마이그레이션 호환성을 위해 로 타입을 지원하고 제네릭 구현에는 소거 방식을 사용하기로 했다. (아이템 28)
• p 158, 제네릭 메서드 (아이템 30)
• p 158, 한정적 와일드카드 타입 (아이템 31)
• Generic DAO 만들기

완벽 공략 40. GenericRepository

자바 Generic을 활용한 중복 코드 제거 예제

• Message(Repository), Account(Repository)는 굉장히 유사하다.
• 제네릭을 사용해 중복 코드를 제거할 수 있다.
• 리팩토링 전에는 테스트 코드가 있어야 검증이 될 수 있으니 꼭 테스트 코드 작성으로 검증 후에 리팩토링을 진행하도록 한다.

public interface Entity {

    Long getId();
}

public class Account implements Entity {

    private Long id;

    private String username;

    public Account(Long id, String username) {
        this.id = id;
        this.username = username;
    }

    @Override
    public Long getId() {
        return this.id;
    }

    public String getUsername() {
        return username;
    }
}

public class AccountRepository {

    private Set<Account> accounts;

    public AccountRepository() {
        this.accounts = new HashSet<>();
    }

    public Optional<Account> findById(Long id) {
        return accounts.stream().filter(a -> a.getId().equals(id)).findAny();
    }

    public void add(Account account) {
        this.accounts.add(account);
    }
}

public class Message implements Entity {

    private Long id;

    private String body;

    @Override
    public Long getId() {
        return id;
    }

    public String getBody() {
        return body;
    }
}

public class MessageRepository {

    private Set<Message> messages;

    public MessageRepository() {
        this.messages = new HashSet<>();
    }

    public Optional<Message> findById(Long id) {
        return messages.stream().filter(a -> a.getId().equals(id)).findAny();
    }

    public void add(Message message) {
        this.messages.add(message);
    }
}

• 리팩토링 후
  • 테스트로 검증 필수
  • 중복이 적어진다.
  • 유지보수 해야 할 코드가 적어진다.

public class GenericRepository<E extends Entity> {

    private Set<E> entities;

    public GenericRepository() {
        this.entities = new HashSet<>();
    }

    public Optional<E> findById(Long id) {
        return entities.stream().filter(a -> a.getId().equals(id)).findAny();
    }

    public void add(E entity) {
        this.entities.add(entity);
    }

}

public class AccountRepository extends GenericRepository<Account> {
}