본문은 Effective Java를 읽고 정리한 내용을 기반으로 작성된 글입니다.
태그 달린 클래스는 클래스 계층구조보다 훨씬 나쁘다!
[태그 달린 클래스]
: 두가지 이상의 의미를 표현할 수 있고, 그 중 현재 표현하는 의미를 태그 값으로 알려주는 클래스
public class Figure {
enum Shape {RECTANGLE, CIRCLE};
// 태그 필드 - 현재 모양을 나타낸다.
final Shape shape;
// 다음 필드들은 모양이 사각형(RECTANGLE)일 때만 쓰인다.
double length;
double width;
// 다음 필드는 모양이 원(CIRCLE)일 때만 쓰인다.
double radius;
// 원용 생성자
public FigureWithTag(double radius) {
this.shape = Shape.CIRCLE;
this.radius = radius;
}
// 사각형용 생성자
public FigureWithTag(double length, double width) {
this.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문을 수정해야함
- 인스턴스의 타입만으로는 현재 나타내는 의미를 알 길이 전혀 없다
객체 지향 언어는 타입 하나로 다양한 의미의 객체를 표현하는 훨씬 나은 수단을 제공함 ↔ 클래스 계층구조
태그 달린 클래스는 클래스 계층구조를 어설프게 흉내낸 아류일 뿐이다
[클래스 계층구조로 바꾸는 방법]
- 계층구조의 루트가 될 추상 클래스 정의
- 태그 값에 따라 달라지는 메서드들 → 루트 클래스의 추상 메서드로 선언
- ex) Figure의 area()
- 태그 값에 상관없이 동작이 일정한 메서드들 → 루트 클래스에 일반 메서드로 추가
- 모든 하위 클래스에서 공통으로 사용하는 데이터 필드들 → 루트 클래스로 추가
- 루트 클래스를 확장한 구체 클래스를 의미별로 하나씩 정의
- ex) Figure를 확장한 Circle, Rectangle 클래스 정의
- 각 하위 클래스에는 각자 의미에 해당하는 데이터 필드 넣기
- ex) Circle에는 radius, Rectangle에는 length와 width
- 루트 클래스가 정의한 추상 메서드를 각자의 의미에 맞게 구현
완성
public abstract class Figure {
abstract double area();
}
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 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;
}
}
- 살아남은 필드들은 모두 final
- 각 클래스의 생성자가 모든 필드를 남김없이 초기화, 컴파일러가 추상 메서드를 모두 구현했는지 확인해준다
- 루트 클래스의 코드를 건드리지 않고도 계층구조 확장 가능
- 타입 사이의 자연스러운 계층 관계 반영 가능 → 컴파일타임 타입 검사 능력을 높여준다
**
이번 예시에서는 코드를 단순하게 하기 위해 접근자 메서드 없이 필드를 직접 노출했지만, 공개할 클래스라면 이런 설계는 좋지 않다(아이템 16)
'Book > 이펙티브 자바' 카테고리의 다른 글
[Effective Java] item 24. 멤버 클래스는 되도록 static으로 만들어라 ** (1) | 2023.12.23 |
---|---|
[Effective Java] item 21+22. 인터페이스는 구현하는 쪽을 생각해 설계하라, 인터페이스는 타입을 정의하는 용도로만 사용하라 (0) | 2023.12.22 |
[Effective Java] item 20. 추상 클래스보다는 인터페이스를 우선하라 * (1) | 2023.12.18 |