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

• 태그 달린 클래스의 단점
  • 쓸데없는 코드가 많다.
  • 가독성이 나쁘다.
  • 메모리도 많이 사용한다.
  • 필드를 final로 선언하려면 불필요한 필드까지 초기화해야 한다.
  • 인스턴스 타입만으로는 현재 나타내는 의미를 알 길이 없다.
• 클래스 계층 구조로 바꾸면 모든 단점을 해결할 수 있다.

태그달린 클래스란?

클래스가 가지고 있는 필드 중 일부가 클래스의 구체적인 타입을 나타내는 경우.

클래스가 어떤 타입인지 정보를 담고 있는 필드를 의미한다.

 

태그 달린 클래스

태그 달린 클래스에는 단점이 한가득이다.

우선 열거 타입 선언, 태그 필드, switch 문 등 쓸데 없는 코드가 많다. (RECTANGLE 입장에서는 radius가 불필요하고 CIRCLE 입장에서는 length와 width가 필요하지 않다.)

여러 구현이 한 클래스에 혼합돼 있어서 가독성도 나쁘다.

다른 도형을 만들기 위한 코드도 언제나 함께 하니 메모리도 많이 사용한다.

필드들을 모두 final로 선언하려면 생성자에서 쓰이지 않는 필드값까지 초기값 세팅을 해야한다.

새로운 도형이 생긴다면 넓이를 구하는 switch 문을 찾아 다시 분기 처리를 추가해야 하는데 하나라도 빠뜨리면 런타임시 문제가 될 수 있다.

마지막으로 인스턴스의 타입만으로는 현재 어떤 도형을 나타내는지 알 수 없다. 그냥 Figure 도형일 뿐 인터페이스 처럼 공통된 타입에 구체적인 타입을 생성하는 것도 아니고 Figure 생성자가 매개변수 1개 받냐 2개 받냐에 따라 사각형과 원으로 나뉘니 알기 어렵다.

 

문제점을 해결하기 위해 상속을 사용한다.

 

계층구조의 루트가 될 추상 클래스를 정의하는데 구현하는 하위 클래스에서 공통적인 값을 가지거나 기능이 있다면 루트 클래스에 정의해준다. 구현하는 하위 클래스 유형마다 동작이 달라지는 메서드들은 추상 메서드로 선언한다. Figure 클래스에서는 area 메서드가 이에 해당한다.

 

루트 클래스를 확장한 구체 클래스는 의미별로 하나씩 정의 한다.

각 하위 클래스에는 각자의 의미에 해당하는 데이터 필드들을 넣으면 된다.

원에는 반지름을, 사각형에는 길이와 너비를 넣는다.

그런 다음 루트 클래스가 정의한 추상 메서드를 각자의 의미에 맞게 구현한다.

태그 달린 클래스의 단점을 모두 날린 계층 구조

각 구체 클래스에서는 자기 자신만 사용하는 데이터 필드값이 들어가 있으니 생성자 초기화 때 초기값 세팅 하면 되니 전부 final로 선언할 수 있다. 추상 메서드도 모두 구현 했는지 컴파일러가 확인해주니 실수로 빼먹은 case문 때문에 런타임 오류가 발생할 일이 없다. 

루트 클래스의 코드를 건드리지 않고 다른 프로그래머들이 독립적으로 계층구조를 확장하고 함께 사용할 수 있다.

생성자 초기화시 매개변수 타입과 갯수를 신경쓰지 않고 구현해도 된다.

또한, 타입 사이의 자연스러운 계층 관계를 반영할 수 있어서 유연성은 물론 컴파일 타입 검사 능력을 높여주는 장점도 있다. 어떻게 보면 리팩토리 관점이라고 볼 수 있다.

 

만약 태그 달린 클래스에 추가를 한다면?

빠진 부분이 없이 모든 부분을 잘 찾아서 구현해야 하며 고민해야 하는 시간이 늘어난다. 정사각형에만 쓰일 필드를 추가하는지 생성자를 추가하는지 생성자를 추가할 경우 매개변수와 타입이 같아 어떻게 해야 하는지 등...