Item 23. 태그 달린 클래스보다는 클래스 계층구조를 활용하라

태그 달린 클래스

class Figure {
    enum Shape { RECTANGLE, CIRCLE };

    // 태그 필드 - 현재 모양을 나타낸다.
    final Shape shape;

    // 다음 필드들은 모양이 사각형(RECTANGLE)일 때만 쓰인다.
    double length;
    double width;

    // 다음 필드는 모양이 원(CIRCLE)일 때만 쓰인다.
    double radius;

    // 원용 생성자
    Figure(double radius) {
        shape = Shape.CIRCLE;
        this.radius = radius;
    }

    // 사각형용 생성자
    Figure(double length, double width) {
        shape = Shape.RECTANGLE;
        this.length = length;
        this.width = width;
    }

    double area() {
        switch(shape) {
            case RECTANGLE:
                return length * width;
            case CIRCLE:
                return Math.PI * (radius * radius);
            default:
                throw new AssertionError(shape);
        }
    }
}

위의 코드는 태그 달린 코드의 예이다. 이러한 태그 달린 클래스에는 단점이 많다.

1. 열거 타입 선언, 태그 필드, switch문 등 쓸데없는 코드가 많다.
   • 여러 구현이 한 클래스에 혼합돼 있어 가독성이 나쁘다.
2. 필드들을 final로 선언하려면 해당 의미에 쓰이지 않는 필드들까지 생성자에서 초기화해야 한다.
3. 또 다른 의미를 추가하려면 코드를 수정해야 한다.
   • 위의 코드에서도 새로운 의미를 추가할 때 마다 모든 switch 문들 찾아 새 의미를 처리하는 코드를 추가해야 한다.

이처럼 태그 달린 클래스는 장황하고, 오류를 내기 쉽고, 비효율적이다.

태그 달린 클래스는 계층구조를 어설프게 흉내낸 아류일 뿐이다.

 

계층구조 클래스

계층구조로 바꾸기

1. 계층구조의 루트(root)가 될 추상 클래스를 정의해라.
2. 태그 값에 따라 동작이 달라지는 메서드들을 루트 클래스의 추상 메서드로 선언해라.(위 코드에서는 area가 해당된다.)
3. 태그 값에 상관없이 동작이 일정한 메서드들을 루트 클래스에 일반 메서드로 추가해라.
4. 하위 클래스에서 공통으로 사용하는 데이터 필드들도 전부 루트 클래스로 올린다.
5. 루트 클래스를 확장한 구체 클래스를 의미별로 하나씩 정의한다.
6. 각 하위 클래스에는 각자의 의미에 해당하는 데이터 필드들을 넣는다.

위의 태그 달린 클래스를 계층구조로 바꾸면 아래와 같이 바꿀 수 있다.

abstract class Figure {
    abstract double area();
}

class Circle extends Figure {
    final double radius;

    Circle(double radius) { this.radius = radius; }

    @Override double area() { return Math.PI * (radius * radius); }
}

class Rectangle extends Figure {
    final double length;
    final double width;

    Rectangle(double length, double width) {
        this.length = length;
        this.width  = width;
    }
    @Override double area() { return length * width; }
}

태그 달린 클래스를 이처럼 계층구조의 클래스로 바꾸어 단점을 해결할 수 있다.

 

타입이 의미별로 따로 존재하니 변수의 의미를 명시하거나 제한할 수 있고, 또 특정 의미만 매개변수로 받을 수 있다.

또한 타입 사이의 자연스러운 계층 관계를 반영할 수 있어 유연성은 물론 컴파일타임 타입 검사 능력을 높여준다는 장점도 있다.

 

예를 들어 위의 Rectangle을 토대로 Square을 추가로 지원하도록 수정한다면 아래와 같이 유연하게 할 수 있다.

class Square extends Rectangle {
    Square(double side) {
        super(side, side);
    }
}

 

마무리

태그 달린 클래스를 써야 하는 상황은 거의 없다. 태그 필드가 등장한다면 태그를 없애고 계층구조로 대체하는 방법을 생각해보자.

기존 클래스가 태그 필드를 사용하고 있다면 계층구조로 리팩터링하는 걸 고민해보자.