1장 객체, 설계

1장 Theater의 개선 과정

• step1 : 절차지향적인 Theater, 데이터와 프로세스가 따로 존재
• step2 : 자율적인 책임을 가지는 객체지향적인 Theater, 데이터와 프로세스가 혼재
• step3 : 자율적인 책임을 가지지만 결합도가 올라가는 Theater

 

1장의 질문 목록

• 모든 소프트웨어 모듈이 가지는 목적은 무엇인가?
• 결합도가 높은 설계의 문제점은 무엇이고 어떻게 해결할 수 있는가?
• 응집도가 높은 객체 설계의 장점은 무엇이고 어떻게 달성할 수 있는가?
• 객체지향은 기존 패러다임인 절차지향 설계의 문제를 어떻게 해결하는가?
• 객체지향 설계의 트레이드오프는 무엇인가?
• 객체지향 세계의 객체는 현실세계의 객체와 무엇이 다른가?

 

1장에서 기억하고 싶은 점

• 소프트웨어 모듈이 가져야 하는 기능 : 모든 모듈은 제대로 실행돼야 하고, 변경이 용이해야하며, 이해하기 쉬워야함.
• 자율적인 객체 만들기 : 자신의 상태를 자기가 책임지고 변경하도록 만들기. 외부의 객체는 자신의 상태를 변경할 수 없으며, 외부 객체가 자신의 상태 변화를 기대하려면 상태를 가진 객체에게 메시지로 요청을 보내야함.
• 변경에 유연한 구조 만들기 : 의존성은 변경 가능성을 암시하므로 객체들의 의존성을 낮춰야함. 불필요한 의존성을 제거함으로써 객체 사이의 결합도를 낮추면 됨. 데이터-프로세스 구조의 경우 프로세스가 모든 데이터에 의존하고 있어 강한 결합이 발생하고 변경에 불리한 구조가 되었음. 구현에 속하는 상태는 바뀌는게 자연스러우므로 외부에서 이 상태에 의존하지 않도록 캡슐화가 필요함. 캡슐화로 구현을 감춰놓으면 객체의 구현이 바뀌더라도 변경 범위가 외부로 퍼지지 않으므로 쉽게 변경 가능.
• 설계의 트레이드 오프 : 책임에 따라 객체를 나누고 협력 관계를 만들다보면, 쪼개기 전과 동일한 기능을 수행하기 위해서 의존성이 추가될 수도 있음. 캡슐화를 한다고 해서 반드시 의존도가 낮아지는 것이 아니므로, 트레이드 오프에 주의해야함. 이는 개발자끼리 상의해서 결합도와 응집도 중 선택해야함.

 

오늘 완성해야하는 기능을 구현하는 코드를 짜는 동시에 내일 쉽게 변경할 수 있는 코드를 짜야한다. 좋은 설계란 오늘 요구하는 기능을 온전히 수행하면서 내일의 변경을 매끄럽게 수용할 수 있는 설계다.

 

 

 

모든 소프트웨어 모듈이 가지는 목적은 무엇인가?

로버트 마틴이 클린 소프트웨어를 통해 제시한 소프트웨어 모듈이 가져야 하는 세 가지 목적은 다음과 같다.

1. 실행 중에 제대로 동작한다.
2. 변경이 용이하다.
3. 이해하기 쉽다.

우리가 작성한 프로그램은 위의 세 가지 요소로 평가한다.

참고로 변경이 용이해야 하는 이유는 소프트웨어 요구사항이 항상 변경되기 때문이다. 개발을 시작하는 시점에 구현에 필요한 모든 요구사항을 수정하는 것을 불가능하다. 오늘 코드를 작성할 때는 내일 변경될 수 있다는 것을 반영해야 한다.

 

 

결합도가 높은 설계의 문제점은 무엇이고 어떻게 해결할 수 있는가?

결합도가 높다는 것은 어떤 클래스가 알고 있는 정보가 많다는 뜻이다. 결합도가 높으면 변경에 취약하고 가독성이 떨어진다. 다음 코드는 결합도가 높은 클래스의 메소드이다.

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);
    }
}

하나의 클래스가 Audience, Bag, Invitaton, Ticket, TicketSeller, TickerOffice에 모두 의존하고 있다. 이 메소드의 논리는 고객의 가방을 꺼내 초대장을 가지고 있다면 매표원이 티켓을 꺼내 고객에게 쥐어주는 것이고, 초대장이 없다면 가방에서 돈을 꺼내고 매표소의 현금 총액을 늘리고 티켓을 고객에게 주는 것이다.

이 코드를 이해하려면 여러 클래스를 뒤져본 후에야 이 논리를 파악할 수 있을 것이다. 이해하기 어렵다. 또 위의 논리는 Audience가 Bag를 들고 있고, Ticket을 현금으로만 계산하고, 돈을 TickerOffice에 보관하는 등 여러 조건을 가정하고 있는데, 클래스에 변경 사항이 생기면 이 클래스를 사용하고 있는 위의 메소드도 변경해야할 것이다. 변경에 취약한 것이다.

위와 같이 데이터 클래스가 따로 있고 여기에 접근해서 동작을 취하는 프로세스가 있는 형태를 절차적 프로그래밍 방식이라고 한다. 절차적 프로그래밍은 프로세스가 필요한 모든 데이터에 의존한다는 근본적인 문제점 때문에 변경에 취약하다.

결합도를 낮추는 개선 작업을 해보자. 결합도가 높은 원인은 클래스가 다른 클래스에 대한 정보를 너무 많이 알고있는 것이었다. 그렇다면 클래스가 다른 클래스의 내부를 모르도록 숨겨야 한다. 객체가 자신의 정보를 스스로 관리하고 동작하는 자율적인 객체로 수정한다. 이때 숨기는 작업을 캡슐화라고 하고, 캡슐화된 객체들은 메시지를 통해 소통한다.

 

 

응집도가 높은 객체 설계의 장점은 무엇이고 어떻게 달성할 수 있는가?

캡슐화를 통해 응집도를 높일 수 있다. 응집도가 높은 객체는 변경이 발생할 때 변경 범위가 객체 내부로 한정되고, 이 객체의 외부에는 영향을 받지 않는다는 장점이 있다. 캡슐화를 하려면 어디까지 숨겨야할지 정하기 위해 객체에 책임을 부여한다. 객체의 책임이 명확해지기 때문에 코드의 가독성도 좋아진다.

아까 살펴본 결합도 높은 메소드를 개선해보자. 이 클래스의 이름은 Theater인데, 이 객체는 관람객을 입장시키는 것일 뿐이다. 가방을 열어 초대권을 확인하고 돈을 지불하는 것은 관람객, 매표소에서 티켓을 꺼내고 관람객에게 티켓을 지급하고 돈을 관리하는 것은 매표원의 역할이다. Audience와 TicektSeller가 자율적인 객체가 될 수 있도록 코드를 재배치하자.

public class Theater {
    // ..
  public void enter(Audience audience) {
    ticketSeller.sellTo(audience);
  }
}

public class TicketSeller {
  // ..
  public void sellTo(Audience audience) {
    Ticket ticket = ticketOffice.getTicket();
    Long ticketFee = audience.buy(ticket);
    ticketOffice.plusAmount(ticketFee);
  }
}

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

TicketSeller는 티켓을 꺼내서 관람객에게 판매하고, 받은 현금을 매표소에 보관하는 돈에 추가한다. Audience는 가방을 열어 초대장 여부를 확인하고, 초대장이 있다면 그냥 티켓을 가진다. 초대장이 없다면 가지고 있는 돈을 차감하고 티켓을 가진다.

자율적인 객체가 되도록 책임을 이동한 덕분에 Theater는 더이상 변경에 취약하지도 않고, 우리의 직관에 들어맞기 때문에 이해하기도 쉬워졌다. 클래스 전체에서도 의존성이 줄어들었기 때문에 훨씬 유연한 설계를 갖추었다.

 

 

객체지향은 기존 패러다임인 절차지향 설계의 문제를 어떻게 해결하는가?

데이터 클래스들이 따로 있고 여기에 접근해서 동작을 취하는 프로세스가 있는 형태를 절차적 프로그래밍 방식이라고 한다. 절차적 프로그래밍은 프로세스가 필요한 모든 데이터에 의존한다는 근본적인 문제점 때문에 변경에 취약하다.

서로에게 의존하지 않도록 객체 내부를 숨기면 된다. 이때 데이터와 프로세스를 하나의 객체에 넣어야 하는데, 코드 배치의 기준은 객체에게 부여한 책임에 따른다. 특정 책임과 관련된 코드가 많을수록 응집도 높은 객체가 된다.

결국 캡슐화를 통해 자율성을 높이고 응집도 높은 객체를 만들 수 있다. 객체들은 서로의 책임만 알고 있어 메시지를 통해서만 의존하므로 결합도를 낮출 수 있다.

불필요한 세부사항을 캡슐화하는 자율적인 객체들이 낮은 결합도와 높은 응집도를 가지고 협력하도록 최소한의 의존성만을 남기는 것이 훌륭한 객체지향설계다.

• 캡슐화 : 객체 내부 상태를 숨김
• 자율적인 객체 : 책임을 객체에게 부여함
• 높은 응집도와 낮은 결합도 : 자율적인 객체들의 집단
• 메시지를 통한 협력 : 애플리케이션 기능을 수행하기 위해 객체들은 서로의 내부를 모른 채 책임만을 보고 메시지를 호출하여 협력함

 

 

객체지향 설계의 트레이드오프는 무엇인가?

설계는 코드를 배치하는 것이다. 객체의 응집도를 증가시키다보면 메시지 전송을 위한 정보를 알게되어 의존도가 늘어날 수 있다. 이럴 때는 토론을 통해 응집도를 증가시킬 것인지 전체의 결합도를 낮출 것인지 결정해야 한다.

결합도를 낮춘다면 기존 객체가 다른 객체에 의존하고 있는 상황을 유지해야할 것이다. 설계는 균형의 예술이다. 트레이드오프 과정이 설계를 어려우면서도 흥미진진한 작업으로 만든다.

Audience 코드에서 가방을 열어 확인하는 작업이 있는데, 의존도를 줄이기 위해 Bag의 응집도를 높였다. 또 TicketSeller가 매표소의 티켓을 꺼내 돈을 증가시키는 작업이 있는데, 의존도를 줄이기 위해 이 작업을 TicketOffice가 하도록 코드를 이동했다.

// Bag
public Long hold(Ticket ticket) {
    if (hasInvitation()) {
        setTicket(ticket);
        return 0L;
    } else {
        setTicket(ticket);
        minusAmount(ticket.getFee());
        return ticket.getFee();
    }
}

// Audience
public Long buy(Ticket ticket) {
    return bag.hold(ticket);
}

// TicketOffice
public void sellTicketTo(Audience audience) {
    Long ticketFee = audience.buy(getTicket());
    plusAmount(ticketFee);
}

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

코드를 이동하다보니 TicketOffice의 응집도는 높아졌지만 Audience에 의존하게 되었다. 상의를 통해 Audience 결합도를 낮추는 방향으로 정했다.

 

 

객체지향 세계의 객체는 현실세계의 객체와 무엇이 다른가?

실세계에서는 생명이 없는 수동적인 존재라고 하더라도 객체지향의 세계로 넘어오는 순간 생명과 지능을 가진 존재가 된다. 이를 의인화라고 한다. 객체들은 객체지향세계에서 능동적이고 자율적인 에이전트가 된다.

1장의 예제에서 극장, 가방, 매표소 등은 실세계에서는 살아있는 존재가 아니다. 하지만 객체지향적인 소프트웨어에서 가방은 스스로의 돈을 관리하고 매표소는 현금 보유량을 줄였다 늘였다 한다. 심지어 추상적인 존재도 객체지향 세계에서는 살아있는 것처럼 동작한다. 소프트웨어의 기능을 위해 책임을 얻고 자율적인 존재가 되어 협력하기 때문이다.