태그 달린 클래스보다는 클래스 계층구조를 활용하라
태그 달린 클래스
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);
}
}
}
태그 달린 클래스의 단점
- 태그 달린 클래스는 열거 타입 선언, 태그 필트, switch문 등 쓸데없는 코드가 많다.
- 여러 구현이 한 클래스에 혼합돼 있어서 가독성이 나쁘다.
- 다른 의미를 위한 코드도 언제나 함께 하니 메모리도 많이 사용한다.
- 필드들을 final로 선언하려면 해당 의미에 쓰이지 않는 필드들까지 생성자에서 초기화해야 한다.
- 생성자가 태그 필드를 설정하고 해당 의미에 쓰이는 데이터 필드들을 초기화하는 데 컴파일러가 도와줄 수 있는 건 없다. 런타임에서야 문제가 드러난다. 의미를 추가하려면 코드를 수정해야 한다.
클래스 계층구조를 활용한 서브타이핑
클래스 계층구조는 태그 달린 클래스의 단점을 모두 날려버린다.
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; }
}
class Square extends Rectangle {
Square(double side) {
super(side, side);
}
}
루트 클래스 Figure를 확장한 구체 클래스를 의미별로 하나씩 정의한 다음 루트 클래스가 정의한 추상 메서드를 각자의 의미에 맞게 구현했다.
클래스 계층구조의 장점
- 각 클래스의 생성자가 모든 필드를 남김없이 초기화하고 추상 메서드를 모두 구현했는지 컴파일러가 확인해준다. 실수로 빼먹은 case문 때문에 런타임 오류가 발생할 일도 없다.
- 루트 클래스의 코드를 건드리지 않고도 계층구조를 확장하고 함께 사용할 수 있다.
- 타입이 의미별로 따로 존재하니 변수의 의미를 명시하거나 제한할 수 있고, 또 특정 의미만 매개변수로 받을 수 있다.
- 타입 사이의 자연스러운 계층 관계를 반영할 수 있어서 유연성은 물론 컴파일타임 타입 검사능력을 높여준다.
태그 달린 클래스를 써야 하는 상황은 거의 없다. 새로운 클래스를 작성하는 데 태그 필드가 등장하면 계층구조로 대처하자.
Comments