[이펙티브 자바] Item23. 태그 달린 클래스보다는 클래스 계층 구조를 활용하라.

 

[이펙티브 자바] Item23. 태그 달린 클래스보다는 클래스 계층 구조를 활용하라. 

두 가지 이상의 의미를 표현할 수 있으며, 그중 현재 표현하는 의미를 태그 값으로 알려주는 클래스를 태그 달린 클래스라고 한다. 

 

public class Figure {
    enum Shape {RECTANGLE, CIRCLE, SQUARE}

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

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

    // 다음 필드는 모양이 원일때만 사용한다.
    double radius;

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

    // 사각형용 생성자
    Figure(double length, double width) {
        if (this.length == this.length) {
            shape = Shape.SQUARE;
        }else {
            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);
        }
    }
}

이렇게 태그 달린 클래스를 사용하면.. 

Shape이 CIRCLE인 경우에는 length, width 는 필요없는데 초기화를 해줘야 하고, RECTANGLE 인 경우에는 radius가 필요없지만 초기화도 해야하고 필드를 가지고 있어야 한다. 

즉, 쓸데없는 코드가 많아지고, 지금은 코드가 짧아 코드 보는데 그리 오래 걸리지 않지만 이게 많아진다면 가독성 역시 나빠져 나중에 코드 파악이 힘들어진다. 

또한 필요없는 데이터를 많이 들고 있어서 메모리도 많이 사용하게 된다. 

 

여기에 위에 처럼 final로 선언하면 불필요한 코드까지 초기화 해야 하기 때문에 번거로워 진다!! 

그리고 인스턴스만으로는 현재 나타내는 의미를 파악하기에 알 길이 없기도 하다. 

 

태그 달린 클래스 단점 

- 쓸데없는 코드가 많다. 

: 열거 타입 선언, 태그 필드, switch문 등 쓸데없는 코드가 많다. 

 

- 가독성이 나쁘다. 

: 여러 구현이 한 클래스에 혼합되어 있어서 가독서이 안좋다. 

 

- 메모리 사용이 많다. 

: 다른 의미를 위해서 코드도 언제나 함께 하기 때문에 메모리도 많이 사용한다. 

 

- 필드들을 final 로 선언하려면 해당 의미에 쓰이지 않는 필드들까지 생성자에서 초기화를 해야하는데 그러면 쓰지 않는 필드를 초기화하는 불필요한 코드가 늘어난다. 

 

- 또 다른 의미를 추가하면 코드를 또 수정해야 한다. 

: 위의 예시로 오면 새로운 의미를 추가한다고 하면 모든 switch문을 찾아 새 의미를 처리하는 코드를 추가해야 하는데, 이때 하나라도 빠뜨리면 역시 런타임문제가 발생할 것이다. 

 

 

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

 

 

따라서 위와 같은 태그 달린 클래스보다는 클래스 계층 구조로 변환하면 위의 단점을 모두 해결할 수 있다!! 

(물론 상속을 하지말라고 그 전 item들에서 주구장창 얘기했지만 ㅋ) 

 

 

public abstract class Figure {
    abstract double area();
}

태그 달린 클래스를 클래스 계층 구조로 만들기 위해서 우선 가장 먼저 계층 구조의 루트 root 가 될 추상 클래스를 정의하고, 태그 값에 따라 동작이 달라지는 메서드들을 루트 클래스의 추상 메서드로 선언한다.  그리고 태그 값에 상관없이 동작이 일정한 메서드들은 루트 클래스의 일반 메서드로 추가해준다. 

Figure를 추상 클래스로 만들고 너비 구하는 메서드만 냅둔다. 

 

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

    public Rectangle(double length, double width) {
        this.length = length;
        this.width = width;
    }

    @Override
    double area() {
        return length * width;
    }
}

public class Circle extends Figure{

    final double radius;

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

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

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

루트 클래스를 확장한 구체 클래스를 의미별로 하나씩 정의하는데 여기선 Figure를 확장한 Circle 원 클래스와 Rectangle 사각형 클래스를 만들면 된다. 그리고 각 하위 크래스에는 각자의 의미에 해당하는 데이터 필드들을 넣는다. 

이런식으로 Figure를 상속해서 사용하면 코드도 간결해지고, final로 선언해서 불필요한 필드까지 초기화하지 않아도 된다. 

 

클래스 계층 구조는 태그 달린 클래스의 단점을 모두 해결해준다. 즉, 코드가 간결하고 명확하며, 쓸데없는 코드 역시 모두 사라졌다! 

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

 

 

🐥 회사에서도 코드를 보면 한 클래스에 사용하지 않는 필드를 계속해서 점점 추가해서 사용하는 경우를 많이 봤고, 점점 그 클래스를 보면서 이게 뭐지? 하는 경우가 늘어나는걸 경험한 적이 있다. 

사실 리팩토링하기에 시간적으로 부족하다, 그리고 다른 사람 코드를 건들면 좀 그렇지 않나? 싶어서 그냥 넘어갔던 경우가 있는데.. 

한번 계층 구조로 나타낼 수 있는 경우라면 클래스 계층 구조로 변경해보는 것도 좋을 것 같다..! 

그리고 상속을 사용한거니까.. 문서화를 잘 해둬야 한다는 것도 기억해주기 !!