01 티켓 판매 애플리케이션 구현하기(step01)

---

출처: 오브젝트 p.13

02 무엇이 문제인가

---

소프트웨어 모듈의 세 가지 목적

모듈이란 크기와 상관 없이 클래스나 패키지, 라이브러리와 같이 프로그램을 구성하는 임의의 요소를 의미한다.

모든 모듈은 제대로 실행되야 하고, 변경에 용이해야 하며, 이해하기 쉬워야 한다.

1. 실행 중에 제대로 동작한다.

• 모든 모듈의 존재 이유

2. 변경을 위해 존재한다.

• 대부분의 모듈이 생명주기 동안 변경되기 때문에 간단한 작업만으로도 변경이 가능해야 한다.
• 변경하기 어려운 모듈은 제대로 동작하더라도 개선해야 한다.

3. 코드를 읽는 사람과 의사소통 한다.

• 읽는 사람과 의사소통할 수 없는 모듈은 개선해야 한다.

예상을 빗나가는 코드

이해 가능한 코드

현재 코드에서의 문제는 관람객과 판매원이 소극장의 통제를 받는 수동적인 존재라는 점이다.

• 이해 가능한 코드란 그 동작이 우리의 예상에서 크게 벗어나지 않는 코드다.

  • 현재의 코드는 우리의 상식과는 너무나도 다르게 동작하기 때문에 코드를 읽는 사람과 제대로 의사소통하지 못한다.

• 하나의 클래스나 메서드에서 너무 많은 세부사항을 다루면 코드를 작성하는 사람뿐만 아니라 코드를 읽고 이해해야 하는 사람 모두에케 큰 부담을 준다.

• 현재 코드에서 가장 심각한 문제: Audience와 TickerSeller를 변경할 경우 Theater도 함께 변경해야 한다.

변경에 취약한 코드

현재 코드는 관람객이 현금과 초대장을 보관하기 위해 항상 가방을 들고 다닌다고 가정한다.
또한 판매원이 매표소에서만 티켓을 판매한다고 가정한다.

• 관람객이 가방을 들고 있지 않다면 어떻게 해야 할까?
• 관람객이 현금이 아니라 신용카드를 이용해서 결제한다면 어떻게 해야 할까?
• 판매원이 매표소 밖에서 티켓을 판매해야 한다면 어떻게 해야 할까?

이런 가정이 깨지는 순간 모든 코드가 일시에 흔들리게 된다.

• 관람객이 가방을 들고 있다는 가정이 바뀐다면?
  • Audience 클래스에서 Bag을 제거해야 한다.
  • Audience의 Bag에 직접 접근하는 Theater의 enter 메서드도 수정해야 한다.

Theater는 관람객이 가방을 들고 있고 판매원이 매표소에서만 티켓을 판매한다는 지나치게 세부적인 사실에 의존에 동작한다.

이러한 세부적인 사실 중 한 가지라도 바뀌면 해당 클래스뿐만 아니라 이 클래스에 의존하는 Theater도 함께 변경해야 한다.

이처럼 다른 클래스가 Audience의 내부에 대해 더 많이 알면 알수록 Audience를 변경하기 어려워진다.

이것은 객체 사이의 의존성(dependency) 과 관련된 문제다.

• 의존성은 변경에 대한 영향을 암시한다.
  • 의존성이라는 말 속에는 어떤 객체가 변경될 때 그 객체에게 의존하는 다른 객체도 함께 변경될 수 있다는 사실이 내포되어 있다.
• 우리의 목표는 애플리케이션의 기능을 구현하는 데 필요한 최소한의 의존성만 유지하고 불필요한 의존성을 제거하는 것이다.

출처: 오브젝트 p.17

객체 사이의 의존성이 과한 경우를 가리켜 결합도(coupling) 가 낮다고 말한다.

• 결합도는 의존성과 관련돼 있기 때문에 결합도 역시 변경과 관련이 있다.
• 설계의 목표는 객체 사이의 결합도를 낮춰 변경이 용이한 설계를 만드는 것이다.

03 설계 개선하기

---

여기서 변경과 의사소통이라는 문제가 서로 엮여 있다는 점에 주목하라.

의도를 정확하게 의사소통하지 못하기 때문에 코드가 이해하기 어려워진 것.

• Theater가 관람객의 가방과 판매원의 매표소에 직접 접근한다는 것은 Theater가 Audience와 TickerSeller에 결합된다는 것을 의미한다.
• 따라서 Audience와 TicketSeller를 변경할 때 Theater도 함께 변경해야 하기 때문에 전체적으로 코드를 변경하기도 어려워진다.

해결 방법은 간단하다.

• Theater가 Audience와 TicketSeller에 관해 너무 세세한 부분까지 알지 못하도록 정보를 차단하면 된다.
  • Theater가 원하는 것은 관람객이 소극장에 입장하는 것뿐이다.
• 따라서 관람객이 스스로 가방 안의 현금과 초대장을 처리하고 판매원이 스스로 매표소의 티켓과 판매 요금을 다루게 한다면 이 모든 문제를 한 번에 해결할 수 있을 것이다.

객체를 자율적인 존재로 만들자!

자율성을 높이자

1단계
Theater의 enter 메서드에서 Ticketoffice에 접근하는 모든 코드를 TicketSeller 내부로 숨기기

Ticketseller에 sellTo 메서드를 추가하고 Theater에 있던 로직을 이 메서드로 옮기자.

• Ticketseller에서 getTicketOffice 메서드가 제거됐다는 사실에 주목하라.

  • ticketoffice의 가시성이 private이고 접근 가능한 퍼블릭 메서드가 더 이상 존재하지 않기 때문에 외부에서는 ticketoffice에 직접 접근할 수 없다. // ticketoffice의 가시성이 private? 어떤걸 말하는지 모르겠다.

  • 결과적으로 ticketoffice에 대한 접근은 오직 Ticketseller 안에만 존재하게 된다.

  • 따라서 Ticketseller는 ticketoffice에서 티켓을 꺼내거나 판매 요금을 적립하는 일을 스스로 수행할 수밖에 없다.

이처럼 개념적이나 물리적으로 객체 내부의 세부적인 사항을 감추는 것은 캡슐화(encapsulation) 라고 부른다.

• 캡슐화의 목적은 변경하기 쉬운 객체를 만드는 것이다.

  • 캡슐화를 통해 객체 내부로의 접근을 제한하면 객체와 객체 사이의 결합도를 낮출 수 있기 때문에 설계를 좀 더 쉽게 변경할 수 있게 된다.

수정된 Theater 클래스 어디서도 ticketOffice에 접근하지 않는다는 사실에 주목하라.

• Theater는 ticketOffice가 TicketSeller 내부에 존재하는 사실을 알지 못한다.

  • 단지 ticketSeller가 sellTo 메시지를 이해하고 응답할 수 있다는 사실만 알고 있을 뿐이다.

• Theater는 오직 TicketSeller의 인터페이스(interface) 에만 의존한다.

  • TicketSeller가 내부에 TicketOffice 인스턴스를 포함하고 있다는 사실은 구현(implementation) 의 영역에 속한다.

• 객체를 인터페이스와 구현으로 나누고 인터페이스만을 공개하는 것은 객체 사이의 결합도를 낮추고 변경하기 쉬운 코드를 작성하기 위해 따라야 하는 가장 기본적인 설계 원칙이다.

출처: 오브젝트 p.21

Theater의 로직을 TicketSeller로 이동시킨 결과, Theater에서 TicketOffice로의 의존성이 제거됐다는 사실을 알 수 있다.

TicketOffice와 협력하는 TicketSeller의 내부 구현이 성공적으로 캡슐화된 것이다.

2단계
TicketSeller 다음으로 Audience의 캡슐화를 개선하자.

TicketSeller와 동일한 방법으로 Audience의 캡슐화를 개선할 수 있다.

Bag에 접근하는 모든 로직을 Audience 내부로 감추기 위해 Audience에 buy 메서드를 추가하자.
TicketSeller의 sellTo 메서드에서 getBag 메서드에 접근하는 부분을 buy 메서드로 옮기자.

public class Audience {
    private Bag bag;

    public Audience(Bag bag) {
        this.bag = bag;
    }

    public long buy(Ticket ticket) {
        if (bag.hasInvitation()) {
            bag.setTicket(ticket);
            return 0L;
        } else {
            bag.setTicket(ticket);
            bag.minusAmount(ticket.getFee());
            return ticket.getFee();
        }
    }
}

• 변경된 코드에서 Audience는 자신의 가방 안에 초대장이 들어있는지를 스스로 확인한다.

• Audience가 Bag을 직접 처리하기 때문에 외부에서는 더이상 Audience가 Bag을 소유하고 있다는 사실을 알 필요가 없다.

• 이제 Audience 클래스에서 getBag 메서드를 제거할 수 있고 결과적으로 Bag의 존재를 내부로 캡슐화할 수 있게 됐다.

이제 TicketSeller가 Audience의 인터페이스에만 의존하도록 수정하자.
TicketSeller가 buy 메서드를 호출하도록 코드를 변경하면 된다.

public class TicketSeller {
    private TicketOffice ticketOffice;

    public TicketSeller(TicketOffice ticketOffice) {
        this.ticketOffice = ticketOffice;
    }

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

• TicketSeller와 Audience 사이의 결합도가 낮아졌다.

• 내부 구현이 캡슐화됐으므로 Audience의 구현을 수정하더라도 TicketSeller에는 영향을 미치지 않는다.

출처: 오브젝트 p.24

캡슐화를 개선한 후에 가장 크게 달라진 점은 Audience와 TicketSeller가 내부 구현을 외부에 노출하지 않고 자신의 문제를 스스로 책임지고 해결한다는 것이다.

다시 말해 자율적인 존재가 된 것이다.

무엇이 개선됐는가