리팩토링 34. 계층 합치기

들어가기 전

이 글은 인프런 백기선님의 강의를 복습하며 작성한 글입니다. 

---

리팩토링 34. 계층 합치기 (Collapse Hierarchy)

• 계층 합치기 의미
  • 상속 구조를 리팩토링하는 중에 기능을 올리고 내리다 보면 자식 / 부모 클래스 코드에 차이가 없는 경우가 있음.
  • 두 클래스의 코드가 차이가 없다는 것은 하나는 불필요한 요소라는 것임. 따라서 이 때, 계층 합치기를 통해서 클래스를 제거할 수도 있다.
• 하위 클래스와 상위 클래스 중에 어떤 것을 없애야 하는가?
  • 둘 중에 보다 이름이 적절한 쪽을 선택.
  • 애매하다면 어느 쪽을 선택해도 문제 없음.

자식 / 부모 클래스 간의 기능을 리팩토링 하는 과정에서 자식 / 부모 클래스에 있는 코드가 동일해지는 경우가 있다. '성의없는 요소'가 발생했다고 볼 수 있다. 왜냐하면 불필요한 요소가 자식 / 부모 클래스 중에 한 군데에 남아있는 것이기 때문이다. 

이런 부분은 '계층 합치기'를 통해서 처리해 볼 수 있다. 상속 구조에서 의미없는 상태가 된 경우에는 의미없는 클래스를 삭제해버리는 것이다. 

---

코드 보기

Reservation / CourtReservation 클래스가 존재한다. 그런데 이 때, CourtReservation이 정말로 필요한 클래스인지 생각해봐야한다. 예를 들어 아래 경우를 가정해보자.

• Reservation 클래스는 현재 CourtReservation 용도로만 사용됨. 
• Reservation 클래스는 앞으로 다른 클래스에 사용되지 않을 수도 있음. 

만약 이런 경우라면 CourtReservation 클래스는 전혀 필요없는 클래스가 된다. 따라서 YAGNI(You aren't Gonna Need It) 법칙에 따라서 CourtReservation의 필드를 Reservation에 합친 후, CourtReservation을 삭제하는 방법이 좋을 수 있다. 이것이 계층 합치기다. 

// 이 클래스는 CourtReservation 용도로만 사용되고 있을 수도 있다.
public class Reservation {
    
    private LocalDateTime startDateTime;
    private LocalDateTime endDateTime;
    private List<String> members;
    private String owner;
    private boolean paid;
}


public class CourtReservation extends Reservation {
    // courtNumber는 상위 클래스에서 필요할 수도 있고, 아닐 수도 있다.
    private String courtNumber;
}

'계층 합치기' 리팩토링은 다음과 같이 진행할 수 있다.

1. CourtReservation의 courtNumber 필드를 필드 올리기로 올려준다. (Refactoring → pull Members Up)
2. CourtReservation 클래스를 지운다. 

결과는 아래와 같다. 

// 이 클래스는 CourtReservation 용도로만 사용되고 있을 수도 있다.
public class Reservation {

    private LocalDateTime startDateTime;
    private LocalDateTime endDateTime;
    private List<String> members;
    private String owner;
    private boolean paid;

    // courtNumber는 상위 클래스에서 필요할 수도 있고, 아닐 수도 있다.
    // CourtReservation 클래스에서 pull up members로 옮겨옴. 
    private String courtNumber;
}