객체, 설계

학습 주제
객체 간 결합도를 낮추어 변경이 용이한 코드를 만들어라.

티켓 판매 애플리케이션 구현

초대장 이벤트를 진행중인 극장의 티켓 발권 애플리케이션 구현

초기 설계 애플리케이션은 Theater 입장 시 아래의 로직을 수행한다.

실제 작동하는 메인 코드는 다음과 같다.

public class Theater {
    private TicketSeller ticketSeller;

    public Theater(TicketSeller ticketSeller) {
        this.ticketSeller = ticketSeller;
    }

    public void enter(Audience audience) {
        if (audience.getBag().hasInvitation()) {
            Ticket ticket = ticketSeller.getTicketOffice().getTicket();
            audience.getBag().setTicket(ticket);
        } else {
            Ticket ticket = ticketSeller.getTicketOffice().getTicket();
            audience.getBag().minusAmount(ticket.getFee());
            ticketSeller.getTicketOffice().plusAmount(ticket.getFee());
            audience.getBag().setTicket(ticket);
        }
    }
}

문제점

Theater 클래스의 enter 메서드 동작을 관람객 관점으로 풀어 써본다.

소극장이 내 가방을 열어서 초대장이 있는지 확인하고 초대장이 있으면 뺏어가서 티켓을 발권하여 내 가방에 넣는다. 만약 초대장이 없으면 내 가방에서 돈을 꺼내고 그 돈을 소극장에 적립한 뒤에 티켓을 내 가방에 넣는다.

티켓 판매자 관점에서 보더라도 자신이 아닌 소극장이 이 모든 행위를 주도하는 것은 어색하다.

로버트 마틴’ 소프트웨어 모듈이 가져야 하는 세가지 기능

1. 제 기능대로 동작한다
2. 변경을 위해 존재한다
3. 코드를 읽는 사람과 의사소통한다

의사소통은 이해 가능한 코드를 작성하는 것이다. 이해 가능한 코드란 그 동작이 우리 예상에서 크게 벗어나지 않는 코드이다.

[현재 코드의 문제점]

• Theater이 너무 많은 클래스의 세부사항을 다루고 있다. ← 예상에서 벗어나게 동작한다
• Audience나 TicketSeller를 변경할 경우 Theater도 함께 변경해야 한다. ← 변경에 취약하다

변경에 취약한 코드

변경에 취약한 코드는 의존성이 높은 코드이다.

문제는 의존성이 높은 코드는 변경이 취약하다.

→ 목표는 기능 구현을 위한 최소한의 의존성만 유지하고 불필요한 의존성을 제거하는 것이다.

지금 Theater 클래스가 의존하고 있는 객체는 다음과 같다. 이렇게 의존성이 높은 경우 객체 간 결합도가 높다고 한다. 결합도를 낮춰서 변경이 용이한 설계를 하는 것이 필요하다.

같은 장 다음 파트에서는 변경이 용이하도록 설계를 바꿔본다.