의존성을 '조절'하기 위해 인터페이스와 구현을 분리하자

조영호님의 오브젝트 챕터1 을 읽고 배운점

객체지향은 객체의 자율성을 높여 응집성을 높이고, 객체간의 의존성을 조절 하여 이해하기 쉽고 변경하기 쉬운 코드를 작성하는 것이 중요하다.

그런데 왜 객체간의 의존성을 '낮추는 것'이 아닌 '조절' 일까?

자율성을 높여보자

다음과 같이 매표원 역할을 하는 TicketSeller 클래스가 있다. 이 클래스는 표를 판매하기 위해 TicketOffice 를 가지고 Audience 파라미터를 참조한다.
의존성 측면에서 보면 문제가 없어보이지만, TicketSeller가 임의로 TicketOffice의 상태를 변경하고 있다.

public class TicketSeller {  
    private TicketOffice ticketOffice;

    public void sellTo(Audience audience) {  
        ticketOffice.plusAmount(audience.buy(ticketOffice.getTicket()));  
    }  
}


public class TicketOffice {
    private Long amount;
    private List<Ticket> tickets = new ArrayList<>();

    public void plusAmount(Long amount) {
        this.amount += amount;
    }
}

해결책으로 TicketOffice에 sellTicketTo() 메소드를 만들어 인터페이스와 구현부를 분리한다.
sellTicketTo()가 인터페이스가 되고, plusAmount()가 구현부가 된다.

public class TicketSeller {  
    private TicketOffice ticketOffice;

   public void sellTo(Audience audience) {
        ticketOffice.sellTicketTo(audience);
   }
}

public class TicketOffice {
    private Long amount;
    private List<Ticket> tickets = new ArrayList<>();

    public void sellTicketTo(Audience audience) {
        plusAmount(audience.buy(getTicket()));
    }

    public void plusAmount(Long amount) {
        this.amount += amount;
    }
}

TicketSeller는 TicketOffice의 sellTicketTo() 를 통해 메세지를 보낼 수 있다는 것만 알고 있고, 내부적으로 어떻게 동작하는지 알지 못하고 알 필요도 없다. 인터페이스와 구현이 분리가 된 것이다.

변경이 필요한 경우, 예를 들어 매표소에서 횡령을 하고싶다면(....) TicketOffice 내부에서만 수정해주면 된다.

TicketOffice 내에서 횡령하는 메소드를 만들고 sellTicketTo() 메소드에서 횡령하는 메소드를 사용하도록 수정하면 된다.
인터페이스를 분리하지 않았다면 TicketOffice에서 횡령하는 메소드를 만들고, TicketSeller 에서도 그 메소드를 사용하도록 수정이 필요하다.

인터페이스와 구현부를 분리함으로서 좀 더 이해하기 쉽고, 변경하기 쉬운 코드가 되었다.

자율성 상승, 그러나 결합도도 상승

인터페이스를 분리하기 전 클래스 다이어그램이다. TicketOffice와 Audience간 연결고리가 없다.

 

 

인터페이스를 분리한 후이다.

문제는 TicketOffice가 Audience를 파라미터로 가지면서 결합도가 상승했다는 것이다.

트레이드 오프

하나의 목표를 위해 다른 하나를 희생하는 것을 트레이드 오프라고 한다. 위의 경우에서도 트레이드 오프가 필요하다.
만약 TicketOffice 의 자율성이 중요하다면 인터페이스를 분리하고 결합도를 상승시키는 희생을 하면 되는 것이고, 결합도를 낮추는게 더 중요하다면 자율성을 희생하면 된다.

결론

이처럼 무엇이 좋다고 단정지을 수 없고 개발자의 선택이다. 나는 예제를 보고 자율성을 선택하는 쪽이 끌렸다. 그렇다면 의존성이 높아질 수 밖에 없다.
이처럼 무조건 의존성을 낮추는 것이 무조건 좋다고 볼 수는 없는 것이다. 또 그렇기 때문에 의존성을 낮추는 것이 객체지향이 아니라, 의존성을 조절하는 것이 객체지향적인 설계인 것이라고 생각한다.