이펙티브 자바 - 5장 : 제네릭

 

5장 제네릭

제네릭은 자바 5부터 사용 가능하고 컬렉션이 담을 수 있는 타입을 컴파일러에게 알려주어 더 안전하고 명확한 프로그래밍을 할 수 있지만 코드가 복잡해진다는 단점이 있다.

이번 장에서는 제네릭의 이점을 최대로 살리고 단점을 최소화하는 방법을 이야기한다.

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

클래스와 인터페이스 선언에 타입 매게변수가 쓰이면 이를 제네릭 클래스 혹은 제네릭 인터페이스라고 이를 총칭해 제네릭 타입이라고 한다.

제네릭 타입을 정의하면 로타입(raw type-타입 매개변수가 없는 제네릭 타입)도 함께 정의하며 제네릭 타입에서 타입 매개변수를 전혀 사용하지 않을 때를 말한다.

<> 정의하여 타입이 무엇인지 필히 적시하자.

public class Item26 {
    private final Collection stamp; // 적시 안하는 경우 : 로 타입
    private final Collection<Stamp> stamp1; // 적시 하는 경우

    public Item26(Collection stamps) {
        this.stamps = stamps;
    }
}

• 로 타입을 쓰면 제네릭이 안겨주는 안전성과 표현력을 모두 잃게 되지만 java의 호환성을 위해서이다.
• List

// static int numElementsInCommon(Set s1, Set s2) { // 잘못 된 예 Set이 무엇인지 모른다.
static int numElementsInCommon(Set<?> s1, Set<?> s2) { // 와일드 카드 타입을 사용하자.
        int result = 0;
        for (Object o1 : s1)
            if(s2.contains(o1))
                result++;
        return result;
    }

• 로 타입은 어떤 타입이든 넣을 수 있어서 타입 불변식을 훼손하기 쉽지만 Collection<?>에는 (null 외에는) 어떤 원소도 넣을 수 없다.

예외의 경우

• class 리터럴에는 로 타입을 사용한다.
  • 자바 명세는 class 리터럴에 매개변수화 타입을 사용하지 못하게 했고 배열과 기본 타입은 허용한다.
  • List.class, String[].class, int.class는 허용하고 List.class와 List<?>.class는 허용하지 않는다.
• 런터임에는 제네릭 타입 정보가 지워지므로 instanceiof 연산자는 비한정적 와일드카드 타입 이외의 매개변수화 타입에는 적용할 수 없다.
  • instanceof를 쓸 경우에는 제네릭 타입을 사용하지 않는편이 좋다

    if (o instanceof Set) {
      Set<?> s = (Set<?>) o;
    }

⇒ 컴파일러 경고를 숨기지 않아야 한다.(아이템27), 소거 방식(아이템28), 제네렉 메서드(아이템30), 한정적 와일드 카드 타입(아이템31)

로 타입을 사용하면 런타임에 예외가 일어날 수 있으니 사용하면 안 된다. 로 타입은 제네릭이 도입 도기 이전 코드와의 호환성을 위해 제공될 뿐이며 Set

참고 용어

한글 용어 : 영문 용어 : 예시 : 아이템

매개변수화 타입 : parameterized type : List : 아이템26

실제 타입 매개변수 : actual type parameter : String : 아이템26

제네릭 타입 : generic type : List : 아이템26,29

정규 타입 매개변수 : formal type parameter : E : 아이템26

비한정적 와일드카드 타입 : unbounded wildcard type : List<?> : 아이템26

로 타입 : raw type : : 아이템29

재귀적 타입 한정 : recursive type bound : <T extends Comparable> : 아이템30

한정적 와일드카드 타입 : bounded wildcard type : List<? extends Number> : 아이템31

제네릭 메서드 : generic method : static List asList(E[] a) : 아이템30

타입 토큰 : type token : String.class : 아이템 33

<> : 다이아몬드 연산자

---

아이템 27 : 비검사 경고를 제거하라

• 제네릭을 사용하다 보면 많은 컴파일러 경고들이 있다. 쉽게 제거할 수 있는 경고들은 할 수 있는 한 모든 비검사 경고를 제거하라.
• 경고를 제거할 수는 없지만 타입 안전하다고 확신할 수 있다면 @SuppressWarings("unchecked") 애너테이션을 달아 경고를 숨기자.
  • @suppressWarings 애너테이션은 항상 가능한 한 좁은 범위에 적용하자.
  • 절대로 클래스에는 하면 안되며 한 줄이 넘는 메서드나 생성자에 달려있으면 지역변수 선언쪽으로 옮기자.

public class Item27 {
    private int size;
    private Object[] elements;
    public <T> T[] toArray(T[] a ){
        if (a.length < size) {
            // 생성한 배열과 매개변수로 받은 배열의 타입이 모두 T[]로 같으므로 올바른 형변환이다.
            @SuppressWarnings("unchecked")
            T[] result = (T[]) Arrays.copyOf(elements, size, a.getClass());
            return result;
        }
        System.arraycopy(elements, 0, a, 0, size);
        if (a.length > size)
            a[size] = null;
        return a;
    }
}

• @SuppressWarings("uinchecked") 애너테이션을 사용할 때면 그 경고를 무시해도 안전한 이유를 항상 주석으로 남겨야 한다.

비검사 경고는 중요하니 무시하지 말자. 안전성이 보장 되면 @SuppressWarings("unchecked") 애너테이션으로 경고를 숨기고 근거를 주석으로 남겨라

---

아이템 28 : 배열보다는 리스트를 사용하라

배열과 제네릭 타입의 차이점

• 배열은 공변(같이 변한다)이다. Sub가 Super의 하위 타입이라면 배열 Sub[]는 배열 Super[]의 하위 타입이 된다.
• 제네릭은 불공변(같이 변하지 않는다)이다. 서로 다른 타입 Type1과 Type2가 있을 때, List은 List의 하위 타입도 아니고 상위 타입도 아니다.

Object[] objectArray = new Long[1];
ObjectArray[0] = "타입이 달라 넣을 수 없다."; // ArrayStoreException을 던진다.
List<Object> ol = new ArrayList<Long>(); // 호환되지 않는 타입이다.
ol.add("타입이 달라 넣을 수 없다.");

• 배열은 실체화 되어 런타임에도 자신이 담기로 한 원소의 타입을 인지하고 확인하고 제네릭은 타입 정보가 런타임에서 소거된다.
• 배열과 제네릭은 잘 어우러지 못하는 이유는 타입이 안전하지 않기 때문이다.

List<String>[] stringLists = new List<String>[1]; // 허용 된다는 가정하에
List<Integer> intList = List.of(42); // 42를 생성한 intList
Object[] objects = stringLists; // object 배열에 stringLists 할당한다.
objects[0] = intList; // objects에 42를 할당한다.
String s = stringLists[0].get(0); // String만 담아있다고 했으나 int가 담겨 있어서 문제가 된다.

public class Chooser<T> {
//    private final Object[] choiceArray;
    private final List<T> choiceArray;

    public Chooser(Collection<T> choices) {
//        this.choiceArray = choices.toArray();
        this.choiceArray = new ArrayList<>(choices);
    }

    public Object choose() {
        Random rnd = ThreadLocalRandom.current();
        return choiceArray.get(rnd.nextInt(choiceArray.size()));
    }
}

⇒ 제네릭(아이템26), 비한정적 와일드카드타입(아이템26), 제네릭 컬레션을 배열로 반환하는 방법(아이템33), 제네릭 타입과 가변인수 메서드(아이템53), @SageVarags 애너테이션으로 대처할 수 있다(아이템32), 주석을 달아도 되지만 경고의 원인을 애초에 제거하자(아이템27)

배열은 공변, 제네릭은 불공변이어서 같이 쓰기 쉽지 않다. 배열은 런타임에는 타입이 안전하지만 컴파일런타임에는 그렇지 않고 제네릭은 반대다. 배열을 리스트로 바꾸는 방법을 적용해보자.

---

아이템 29 : 이왕이면 제네릭 타입으로 만들어라

제공되는 제네릭은 사용하기 쉽지만 만드는건 조금 더 어려우니 연습해보자.

보통 를 많이 사용한다.

public class Stack<E> {
//    private E[] elements;
    private Object[] elements; // 방법 2. Object로 받으면 pop에서 꺼낼 때 형변환이 안전하지 않아 비검사 형변환 오류가 난다.
    private int size;
    private static final int DEFAULT_INNITAL_CAPACITY = 16;

    @SuppressWarnings("unchecked")
    public Stack() {
//        this.elements = new E[DEFAULT_INNITAL_CAPACITY];
        this.elements = (E[]) new Object[DEFAULT_INNITAL_CAPACITY]; // 방법1. 항상 E이므로 비검사 형변환은 확실히 안전하다.
    }

    public void push(E e) {
        ensurCapacity();
        elements[size++] = e;
    }

    private void ensurCapacity() {
        if (elements.length == this.size)
            elements = Arrays.copyOf(elements, 2 * size + 1);
    }
    public boolean isEmpty() {
        return size == 0;
    }

    public E pop() {
        if (size ==0)
            throw new EmptyStackException();
        @SuppressWarnings("unchecked")
        E result = (E) elements[--size]; // Object에서 꺼낼 때 항상 E이므로 비검사 형변환도 확실히 안전하다.
        elements[size] = null;
        return result;
    }

        public static void main(String[] args) {
        Stack<String> stack = new Stack<>();
        for (String arg : args)
            stack.push(arg);
        while (!stack.isEmpty()) {
            System.out.println(stack.pop().toUpperCase(Locale.ROOT));
        }

    }
}

• 1번 방법은 가독성이 좋고 확실하게 E타입의 배열을 선언하여 한번만 형변환을 해주면 되고 코드가 짧다.
• 2번 방법은 데이터를 꺼낼 때마나 형변환을 해주어야 한다.
• 1번과 2번 방법 중 1번 방법을 선호하지만 배열 런타임 타입이 컴파일 타임 타입과 달리 힙 오염을 일으켜서 힙 오염이 걸리는 프로그래머는 2번 방법을 고수한다.
• 배열보다는 리스트를 우선하라는 아이템 28과는 모순돼 보이지만 제네릭 타입 안에서 리스트를 사용하는게 항상 가능하지도, 꼭 더 좋은것도 아니다.
  • 자바가 리스트를 기본 타입으로 제공하지 않으므로 ArrayList 같은 제네릭 타입도 결국은 기본 타입인 배열을 사용해 구현해야 하고 HashMap 같은 제네릭 타입은 성능을 높일 목적으로 배열을 사용하기도 한다.

⇒ 매개변수를 추가하는 일이 우선이다.(아이템68), @SuppressWarings 애너테이션으로 경고를 숨긴다.(아이템27), 힙 오염(아이템32), 박싱된 기본 타입(아이템61)

클라이언트에서 직접 형변환해야 하는 타입보다 제네릭 타입이 더 안전하고 쓰기 편하므로 새로운 타입을 설계할 때는 형변환 없이도 사용할 수 있도록 제네릭 타입으로 만들자. 그러면 기존 클라이언트에는 아무 영향을 주지 않으면서, 새로운 사용자를 휠씬 편하게 해주는 길이다.

---

아이템 30 : 이왕이면 제네릭 메서드로 만들어라

클래스와 마찬가지로 메서드도 제네릭으로 만들 수 있으며 매개변수화 타입을 받는 정적 유틸리티 메서드는 보통 제네릭이다.

//    public static Set union(Set s1, Set s2) {
public static <E> Set<E> union(Set<E> s1, Set<E> s2) {
//        Set result = new HashSet(s1);
    Set<E> result = new HashSet(s1);
    result.addAll(s2);
    return result;
}

public static void main(String[] args) {
    Set<String> guys = Set.of("톰", "딕", "해리");
    Set<String> stooges = Set.of("래리", "모에", "컬리");
    Set<String> aflCio = union(guys, stooges);
    System.out.println(aflCio);
}

• (타입 매개변수들을 선언하는) 타입 매개변수 목록은 메서드의 제한자와 반환 타입 사이에 온다.
  • 위 코드에서는 타입 매개변수 목록은 이고 반환 타입은 Set이다.
• 매개 변수의 명명 규칙은 제네릭 메서드나 제네릭 타입이나 똑같다.

private static UnaryOperator<Object> IDENTITY_FN = (t) -> t;
@SuppressWarnings("unchecked")
public static <T> UnaryOperator identityFunction() {
    return (UnaryOperator) IDENTITY_FN;
}

String[] strings = {"삼베", "대마", "나일론"};
UnaryOperator<String> sameString = identityFunction();
for (String s : strings)
    System.out.println(sameString.apply(s));

Number[] numbers = {1, 2.0, 3L};
UnaryOperator<Number> sameNumber = identityFunction();
for (Number n : numbers)
    System.out.println(sameNumber.apply(n));

• 제네릭은 런타임에 타입 정보가 소거되므로 하나의 객체를 어떤 타입으로든 매개변수화할 수 있도록 정적 팩터리를 만들어야 하며 이를 제네릭 싱글턴 팩터리라고 한다.
• 자기 자신이 들어간 표현식을 사용하여 타입 매개변수의 허용 범위를 한정할 수 있는데 재귀적 타입 한정이며 이는 주로 타입의 자연적 순서를 정하는 Comparable 인터페이스와 함께 쓰인다.

    public static <E extends Compable<E>> E max(Collection<E> c); // 모든 타입 E는 자신과 비교할 수 있다.

⇒ 제네릭 메서드나 제네릭 타입이나 똑같다.(아이템29,68), 한정적 와일드카드 타입(아이템31), 소거(아이템28), 함수 객체(아이템42), Function.identity(아이템59), Comparable 인터페이스(아이템14), Optional<E>를 반환하도록 고치는 편이 나을것이다.(아이템55), 셀프타입 관용구(아이템2)

메서드보다는 제네릭 메서드가 더 안전하며 사용하기도 쉽다. 타입과 마찬가지로 메서드도 형변환 없이 사용할 수 있는 편이 좋으며, 많은 경우 그렇게 하라면 제네릭 메서드가 되어야 한다.

---

아이템 31 : 한정적 와일드카드를 사용해 API 유연성을 높이라

매개변수화 타입은 불공변이다. 예를 들어 List은 List

public void pushAll(Iterable<? extends E> src){
        for (E e : src)
            push(e);
    }
public void popAll(Collection<? super E> det) {
        while (!isEmpty())
            det.add(pop());
    }

• 유연성을 극대화하려면 원소의 생산자나 소비자용 입력 매개변수에 와일드카드 타입을 사용하라.
• 입력 매개변수가 생산자와 소비자 역할을 동시에 한다면 와일드카드 타입을 써도 좋을게 없고 타입을 정확히 지정해야 하는 상황에는 와일드 카드를 쓰지 말아야 한다.
• 어떤 와일드카드를 써야 하는지 도움이 되는 방법
  • 펙스(PECS) : producer-extends, consumer-super , 나프탈린과 오들러는 이를 겟풋 원칙이라 부른다.
  • 매개변수화 타입 T가 생산자라면 <? extends T>를 사용한다.
    • 예를 들어 push All의 src 매개변수는 Stack이 사용할 E 인스턴스를 생산하므로 Iterable<? extends E>이다
  • 매개변수화 타입 T가 소비자라면 <? super T>를 사용한다.
    • 예를 들어 popAll의 dst 매개변수는 Stack으로부터 E 인스턴스를 소비하므로 Iterable<? super E>이다.
• 제대로 사용하면 클라이언트는 와일드카드 타입이 쓰인지 의식하지 않아도 되며 클래스 사용자가 와일드카드 타입을 신경 써야 한다면 그 API에 무슨 문제가 있을 가능성이 크다.
• 매개변수는 메서드 선언에 정의한 변수이고, 인수는 메서드 호출 시 넘기는 '실제값'이다.
  • void add(int value) { .. } : 매개변수, add(10) : 인수
  • class Set { .. } : 매개 변수, Set : 인수

public static <E extends Comprable<? super E>> E max( List<? extends E> list) // 이 책에서 가장 복잡한 코드이다.

• Comparable보다는 Comparable<? super E>를 사용하는 편이 낫고 Comparator도 마찬가지로 Comparator보다는 Compartor<? super E>를 사용하는 편이 낫다.

public static <E> void swap(List<E> list, int i, int j){} // 비한정적 타입 매개변수

public static void swap(List<?> list, int i, int j) {} // 비한정적 와일드카드

• public API를 사용하려면 2번인 비한정적 와일드 카드가 나으며 어떤 리스트든 넘기면 명시한 인덱스의 원소들을 교환해주고 신경 써야 할 타입 매개변수도 없다.
• 메서드 선언에 타입 매개변수가 한 번만 나오면 와일드 카드로 대체하라.
  • 비한정적 타입 매개변수이면 비한정적 와일드카드로 바꾸고, 한정적 타입 매개변수라면 한정적 와일드카드로 바꾸면 된다.

public static void swap(List<?> list, int i, int j) {
//        list.set(i, list.set(j, list.get(i))); // 컴파일 오류
    swapHelper(list, i, j);
}

private static <E> void swapHelper(List<E> list, int i, int j) {
    list.set(i, list.set(j, list.get(i)));  // 항상 꺼낸 값이 E 타입의 값임을 알고 있어 안전하다.
}

⇒ 리스코프 치환 법칙(아이템10), 자신을 확장한 것은 아니기 때문이다.(아이템29), 비한정적 타입 매개변수(아이템30)

와일드카드 타입을 적용하면 API가 훨씬 유연해진다. 널리 쓰일 라이브러리라면 반드시 와일드카드 타입을 적절히 사용해야한다.
PECS 공식 : 생산자(producer)는 extends를, 소비자(consumer)는 super를 사용한다.
Comparable과 Comparator는 모두 소비자이다.

---

아이템 32 : 제네릭과 가변인수를 함께 쓸 때는 신중하라

가변 인수 메서드와 제네릭은 자바 5 때 함께 추가되어 잘 어우러질거 같지만 그렇지 않다.

• 가변인수는 구현 방식에 허점이 있는데 가변 인수를 담기 위한 배열을 자동으로 하나 만들고 내부로 감춰야하지만 클라이언트에 노출하여 문제가 된다.
  • 이로 인해 varags 매개변수에 제네릭이나 매개변수화 타입이 포함되면 알기 어려운 컴파일 경고가 발생한다.
  • 매개변수화 타입의 변수가 타입이 다른 객체를 참조하면 힙 오염이 발생한다.
• 제네릭 varargs 배열 매개변수에 값을 저장하는 것은 안전하지 않다.
  • 재네릭 배열을 프로그래머가 직접 생성하는건 허용하지 않으면서 제네릭 varargs 매개변수를 받는 메서드를 선언할 수 있게 한 이유는 제네릭이나 매개변수화 타입의 varargs 매개변수를 받는 메서드가 실무에서 매우 유용하기 때문이다.
  • 에를 들어 Arrays.asList(T... a), Collections.addAll(collection<? super T> c, T... elements), EnumSet.of(E first, E... rest)가 대표적이다.
• @SageVarargs 애너테이션은 메서드 작성자가 그 메서드가 타입 안전함을 보장하는 장치다.
• 메서드가 이 배열에 아무것도 저장하지 않고(그 매개변수들을 덮어쓰지 않고0 배열의 참조가 밖으로 노출되지 않는다면(신뢰할 수 없는 코드가 배열에 접근할 수 없다면) 타입 안전하다.
  • varargs 매개변수 배열이 호출자로부터 그 메서드로 순수하게 인수들을 전달하는 일만 한다면(vararge의 목적대로만 쓰인다면) 그 메서드는 안전하다.
• 제네릭 varargs 매개변수 배열에 다른 메서드가 접근하도록 허용하면 안전하지 않다.
  • @Sagevarargs로 제대로 애노테이트된 또 다른 varargs 메서드에 넘기는 것은 안전하다.
  • 그저 이 배열 내용의 일부 함수를 호출만 하는(varargs를 받지 않는) 일반 메서드에 넘기는 것도 안전하다.

//    @SafeVarargs
//    static <T> List<T> flatten(List<? extends T>... lists) {
    static <T> List<T> flatten(List<List<? extends T>>lists) {
        List<T> result = new ArrayList<>();
        for (List<? extends T> list : lists)
            result.addAll(list);
        return result;
    }

• 제네릭이나 매개변수화 타입의 varargs 매개변수를 받는 모든 메서드에 @SafeVarargs를 달자
• 다음 두 조건을 모두 만족하는 제네릭 varargs 메서드는 안전하다.
  • varargs 매개변수 배열은 아무것도 저장하지 않는다.
  • 그 배열(혹은 복제본)을 신뢰할 수 없는 코드에 노출하지 않는다.
• @SafeVarargs 애너테이션은 재정의할 수 없는 애너테이션에 사용해야 한다.

⇒ 가변인수 메서드(아이템53), @SuppressWarngins("unchecked")(아이템27)

가변인수와 제네릭은 궁합이 좋지 않은데 가변인수 기능은 배열을 노출하여 추상화가 완벽하지 못하고, 배열과 제네릭의 타입 규칙이 서로 다르기 때문이다.

---

아이템 33 : 타입 안전 이종 컨테이너를 고려하라

• 제네릭은 Set, Map<K,V> 등의 컬렉션과 ThreadLocal, AtomicReference 등의 단일 원소 컨테이너에도 흔히 쓰인다.
  • 이런 모든 쓰임에서 매개변수화되는 대상은 (원소가 아닌) 컨테이너 자신이다.
  • 예를 들어 Set에는 원소의 타입을 뜻하는 단 하나의 탕비 매개변수만 있으면 되며, Map에는 키와 값의 타입을 뜻하는 2개만 필요한 식이다.
• 컨테이너 대신 키를 매개변수화 한 다음, 컨테이너에 값을 넣거나 뺄 때 매개변수화한 키를 함께 제공하면 제네릭 타입 시스템이 값의 타입이 키와 같음을 보장하며 이런 설계 방식을 타입 안전 이종 컨테이너 패턴이라고 한다.
  • 각 타입의 Class 객체를 매개변수화한 키 역할로 사용하면 되는데 이 방식이 동작하는 이유는 class의 클래스가 제네릭이기 때문이다.
  • 컴파일타임 타입 정보와 런타임 타입 정보를 알아내기 위해 메서드들이 주고받는 class 리터럴을 타입 토큰이라 한다.

public class Favorites { // 비한정적 토큰 방식
    private Map<Class<?>, Object> favorites = new HashMap<>();
    public <T> void putFavorite(Class<T> type, T instance){
        favorites.put(Objects.requireNonNull(type), instance)
    }
    public <T> T getFavorite(Class<T> type){
        return type.cast(favorites.get(type));
    }

    public static void main(String[] args) {
        Favorites f = new Favorites();

        f.putFavorite(String.class, "Java");
        f.putFavorite(Integer.class, 0xcafebabe);
        f.putFavorite(Class.class, Favorites.class);

        String favoriteString = f.getFavorite(String.class);
        int favoriteInteger = f.getFavorite(Integer.class);
        Class<?> favoriteClass = f.getFavorite(Class.class);

        System.out.printf("%s %x %s %n", favoriteString, favoriteInteger, favoriteClass);
    }
}

• 제약 사항
  • 악의적인 클라이언트가 Class 객체를(제네릭이 아닌) 로 타입으로 넘기면 Favorites 인스턴스의 타입 안전성이 깨지만 컴파일할 때 비검사 경고가 나타난다.
  • 실체화 불가 타입에는 사용할 수 없는데 이는 String이나 String[]은 저장할 수 있지만 List은 저장알 수 없다. List용 Class 객체를 얻을 수 없다.
• 한정적 타입 토큰은 단순히 한정적 타입 매개변수나 한정적 와일드카드를 사용하여 표현 가능한 타입을 제한하는 타입 토큰이다.

static Annotation getAnnotation(AnnotatedElement element, String annotationTypeName) {
        Class<?> annotationType = null;
        try {
            annotationType = Class.forName(annotationTypeName);
        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
        return element.getAnnotation(annotationType.asSubclass(Annotation.class));

    }

⇒ 로타입(아이템26), 실체화 불가 타입(아이템28), 한정적 타입 매개변수(아이템29), 한정적 와일드 카드(아이템31), 애너테이션 API(아이템39), 비검사(아이템27)

컬렉션 API로 대표되는 일반적인 제네릭 형태에서는 한 컨테이너가 다룰 수 있는 타입 매개변수의 수가 고정되어 있는데 컨테이너 자체가 아닌 키를 타입 매개변수로 바꾸면 이런 제약이 없는 타입 안전 이종 컨테이너를 만들 수 있다. 타입 안전 이종 컨테이너는 Class를 키로 쓰며, 이런 식으로 쓰이는 Class 객체를 타입 토큰이라 한다. 또한, 직접 구현한 키 타입도 쓸 수 있다. 예컨대 데이터베이스의 행(컨테이너)을 표현한 DatabaseRow 타입에는 제네릭 타입인 Column를 키로 사용할 수 있다.