public class Figure {
enum Shape { RECTANGLE, CIRCLE };
final Shape shape;
double length;
double width;
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로 선언하려면 해당 의미에 쓰이지 않는 필드들까지 생성자에서 초기화해야 한다.
- 생성자가 태그 필드를 설정하고 해당 의미에 쓰이는 데이터 필드들을 초기화하는 데 컴파일러가 도와줄 수 있는 건 별로 없다.
- 또 다른 의미를 추가하려면 코드를 수정해야 한다. (예. 모든 switch 문을 찾아 새 의미를 처리하는 코드 추가)
- 인스턴스의 타입만으로는 현재 나타내는 의미를 알 길이 전혀 없다.
자바와 같은 객체 지향 언어는 타입 하나로 다양한 의미의 객체를 표현하는 훨씬 나은 수단(클래스 계층구조를 활용하는 서브타이핑)을 제공한다.
- 계층구조의 루트(root)가 될 추상 클래스를 정의한다.
- 태그 값에 따라 동작이 달라지는 메서드들을 루트 클래스의 추상 메서드로 선언한다.
- 태그 값에 상관없이 동작이 일정한 메서드들을 루트 클래스에 일반 메서드로 추가한다. 모든 하위 클래스에서 공통으로 사용하는 데이터 필드들도 전부 루트 클래스로 올린다.
abstract class Figure {
abstract double area();
}
- 루트 클래스를 확장한 구체 클래스를 의미별로 하나씩 정의한다. 각 하위 클래스에는 각자의 의미에 해당하는 데이터 필드들을 넣는다.
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);
}
}