[오브젝트] 1장 객체, 설계

 

이론이 먼저일까, 실무가 먼저일까?

로버트 L. 글래스

1. 티켓 판매 어플리케이션 구현하기

요구사항

소극장의 홍보를 위해 추첨을 통해 관객들에게 무료 공연 초대권을 발송한다. 

 

관람객의 소지품은 초대장, 현금, 티켓으로 제한하고 이를 보관할 용도의 가방을 들 고 온다.

 

클래스 구현

관람객이 소지품을 보관할 Bag 클래스를 추가하고, 초대장의 보유 여부를 판단하는 hasInvitation 메서드와 티켓의 소유 여부를 판단하는 hasTicket 메서드, 현금을 변화시키는 plusAmount, minusAmount 메서드, 그리고 초대장을 티켓으로 교환하는 setTicket 메서드를 구현한다.

 

Bag 인스턴스의 상태는 현금과 초대장을 함께 보관하거나, 초대장 없이 현금만 보관하는 두 가지 상태중 하나이다. 

이제는 관람객 개념을 구현하기 위한 Audience 클래스를 만들 차례다. 관램객은 소지품을 보관하기 위해 Bag을 소지할 수 있다. 

 

매표소에는 관람객에게 판매할 티켓과 티켓의 판매 금액이 보관되어 있어야 한다. 매표소를 구현하기 위해 TicketOffice 클래스를 추가한다. TicketOffice는 판매하거나 교환해 줄 티켓의 목록과 판매 금액을 인스턴스 변수로 포함한다. 티켓을 판매하는 getTicket 메서드는 편의를 위해 tickets 컬렉션에서 맨 첫 번째 위치에 저장된 Ticket을 반환하는 것으로 구현하였다. 또한 판매금액을 더하거나 차감하는 plusAmount와 minusAmount 메서드도 구현돼있다.

판매원을 구현한 TicketSeller 클래스는 자신이 일하는 매표소(TicketOffice)를 알고 있어야 한다.

 

소극장을 구현하는 클래스는 Theater이다. Theater 클래스에는 관람객을 맞이할 수 있는 enter 메서드가 구현되어 있다.  

 

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

 

 

• 관램객의 가방 안에 초대장이 들어있는지 확인한다.
• 만약 초대장이 있다면 이벤트에 당첨된 관램객이므로 판매원에게서 받은 티켓을 관람객의 가방 안에 넣어준다. 
• 만약 초대장이 없다면 티켓을 판매한다.
  • 소극장은 관램객의 가방에서 티켓 금액 만큼을 차감한 후 매표소에 금액을 증가시킨다.
  • 마지막으로 소극장은 관람객의 가방 안에 티켓을 넣어줌으로써 관램객의 입장 절차를 끝낸다.

 

2. 무엇이 문제인가?

로버트 마틴의 <클린 소프트웨어: 애자일 원칙과 패턴, 그리고 실천 방법>에서 설명하는 소프트웨어 모튤이 가져야 하는 세 가지 기능은 아래와 같다.

 

1. 첫 번째 목적은 실행 중에 제대로 동작하는 것이다. 이것은 모듈의 존재 이유라고 할 수 있다.
2. 두 번째 목적은 변경을 위해 존재하는 것이다. 변경하기 어려운 모듈은 제대로 동작하더라도 개선해야 한다.
3. 세 번째 목적은 코드를 읽는 사람과 의사소통하는 것이다. 모듈은 언제나 개발자가 쉽고 읽고 이해할 수 있어야 한다.

 

정리하자면 모듈은 정상적으로 실행되어야 하고, 변경에 용이해야 하며, 이해하기 쉬어야 한다.

 

위에서 작성한 Theater 클래스는 관람객들을 입장시키는 데 필요한 기능을 정상적으로 수행하고 있지만, 변경 용이성과 읽는 사람과의 의사소통이라는 목적은 충족시키지 못하고 있다. 이유를 살펴보자.

 

예상을 빗나가는 코드

Theater 클래스의 enter 메서드가 수행하는 일을 말로 풀어보자.

 

소극장은 관램객의 가방을 열어 그 안에 초대장이 들어 있는지 살펴본다. 가방 안에 초대장이 들어 있으면 판매원은 매표소에 보관돼 있는 티켓을 관람객의 가방 안으로 옮긴다. 가방 안에 초대장이 들어 있지 않다면 관람객의 가방에서 티켓 금액만큼의 현금을 꺼내 매표소에 적립한 후에 매표소에 보관돼 있는 티켓을 관람객의 가방 안으로 옮긴다.

 

문제는 관람객과 판매원이 소극장의 통제를 받는 수동적인 존재인 점이다. 소극장이 초대장을 확인하기 위해 관람객의 가방을 마음대로 열어보고, 티켓을 꺼내 관람객의 가방에 집어넣고 관람객에서 받은 돈을 매표소에 적립하는 일은 판매원이 아닌 소극장이 수행하기 때문이다.

 

이해 가능한 코드란 그 동작이 우리의 예상에서 크게 벗어나지 않아야 하는 코드이다. 하지만 위에서 살펴본 예제는 우리의 예상을 크게 벗어난다. 코드를 읽는 사람과 제대로된 의사 소통을 하고 있지 않는다.

 

현재 코드의 문제점은 Theater의 enter 메서드를 이해하기 위해서는 Audience가 Baag을 가지고 있고, Bag 안에는 현금과 티켓이 들어 있으며 TicketSeller가 TicketOffice에서 티켓을 판매하고, TicketOffice안에 돈과 티켓이 보관돼 있다는 모든 사실을 동시에 기억하고 있어야 한다는 점이다. 하지만 더 심각한 문제점은 Audience와 TicketSeller를 변경할 경우 Theater도 함께 변경해야 한다는 사실이다.

 

변경에 취약한 코드

우리의 코드는 관람객이 현금과 초대장을 보관하기 위해 가방을 들고 다닌다고 가정하고 있다. 

하지만

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

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

 

이것은 객체 사이의 의존성(dependency)과 관련된 문제이다. 의존성이라는 말 속에는 어떤 객체가 변경될 때 그 객체에게 의존하는 다른 객체도 함께 변경될 수 있다는 사실이 내포돼 있다.

 

그렇다고 해서 객체 사이의 의존성을 완전히 없애는 것이 정답은 아니다. 객체지향 설계는 서로 의존하면서 협력하는 객체들의 공동체를 구축하는 것이다. 따라서 우리의 목표는 애플리케이션의 기능을 구현하는 데 필요한 최소한의 의존성만 유지하고 불필요한 의존성을 제거하는 것이다. 

 

객체 사이의 의존성이 과한 경우를 가리켜 결합도(coupling)가 높다고 말한다. 반대로 객체들이 합리적인 수준으로 의존할 경우에는 결합도가 낮다고 말한다. 두 객체 사이의 결합도가 높으면 높을수록 함께 변경될 학률도 높아지기 때문에 객체 사이의 결합도를 낮춰 변경이 용이한 설계를 만들어야 한다.

 

3. 설계 개선하기

코드를 이해하기 어려운 이유는 Theater가 관람객의 가방과 판매원의 매표소에 직접 접근하여, 관람객과 판매원이 자신의 일을 스스로 처리하지 못하게 하고 있다. 따라서 Audience와 TicketSeller를 변경할 때 Theater도 함께 변경해야 하기 때문에 전체적으로 코드를 변경하기도 어려워진다.

 

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

 

다시 말해 관람객과 판매원을 자율적인 존재로 만들면 되는 것이다. 

 

자율성을 높이자

 

자율적인 존재가 되도록 설계를 변경하여 보자.

 

첫 번째 단계는 Theater의 enter 메서드에서 TicketOffice에 접근하는 모든 코드를 TicketSeller 내부로 숨기는 것이다. TicketSeller에 sellTo 메서드를 추가하고 Theater에 있던 로직을 이 메서드로 옮기자.

 

public class TheaterSeller {
    private TicketOffice ticketOffice;
 
    public Theater(TicketOffice ticketOffice) {
        this.ticketOffice = ticketOffice;
    }
 
    public void sellTo(Audience audience) {
        if(audience.getBag().hasInvitation()) {
            Ticket ticket = ticketOffice.getTicket();
            audience.getBag().getTicket(ticket);
        } else {
            Ticket ticket = ticketOffice.getTicket();
            audience.getBag().minusAmount(ticket.getFee());
            ticketOffice.plusAmount(ticket.getFee());
            audience.getBag().setTicket(ticket);
        }
    }
}
 
public class Theater {
    private TicketSeller ticketSeller;
 
    public Theater(TicketSeller ticketSeller) {
        this.ticketSeller = ticketSeller;
    }
 
    public void enter(Audience audience) {
        ticketSeller.sellTo(audience);
    }
}

 

이렇게 개념적이나 물리적으로 객체 내부의 세부적인 사항을 감추는 것을 캡슐화(encapsulation)라고 부른다. 캡슐화를 통해 객체 내부로의 접근을 제한하면 객체와 객체 사이의 결합도를 낮출 수 있기 때문에 설계를 좀 더 쉽게 변경할 수 있게 된다. 

 

이런 식으로 Audience의 캡슐화를 개선할 수 있다. Bag에 접근하는 모든 로직을 Audience 내부로 감추는 방법을 사용하면 된다. 

 

public class Audience {
    private Bag bag;
 
    public Audience(Bag bag) {
        this.bag = bag;
    }
 
    public Long buy(Ticket ticket) {
        if(bag.hasInvitation()) {
            bag.getTicket(ticket);
            return 0;
        } else {
            bag.minusAmount(ticket.getFee());
            bag.setTicket(ticket);
            return ticket.getFee();
        }
    }
}
 
public class TheaterSeller {
    private TicketOffice ticketOffice;
 
    public Theater(TicketOffice ticketOffice) {
        this.ticketOffice = ticketOffice;
    }
 
    public void sellTo(Audience audience) {
        iticketOffice.plusAmount(audience.buy(ticketOffice.getTicket()));
    }
}

 

변경된 코드에서 Audience는 자신의 가방 안에 초대장이 들어있는지를 스스로 확인하여 제3자가 자신의 가방을 열어보도록 허용하지 않는다. 또한 Audience가 Bag을 직접 처리하기 때문에 외부에서는 더 이상 Audience가 Bag을 소유하고 있다는 사실을 알 필요가 없다.

 

무엇이 개선됐는가

수정된 Audience와TicketSeller는 자신이 가지고 있는 소지품을 스스로 관리한다. 코드를 읽는 사람과의 의사소통이라는 관점에서 이 코드는 확실히 계션된 것으로 보인다.

 

어떻게 한 것인가

자기 자신의 문제를 스스로 해결하도록 코드를 변경하였다. 우리는 우리의 직관을 따랐고 그 결과로 코드는 변경이 용이하고 이해 가능하도록 수정됐다.

 

캡슐화와 응집도

핵심은 객체 내부의 상태를 캡슐화하고 객체 간에 오직 메시지를 통해서만 상호작용하도록 만드는 것이다. 밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 위임하는 객체를 가리켜 응집도(cohesion)가 높다고 말한다. 자신의 데이터를 스스로 처리하는 자율적인 객체를 만들면 결합도를 낮출 수 있을뿐더러 응집도를 높일 수 있다.

 

외부의 간섭을 최대한 배제하고 메시지를 통해서만 협력하는 자율적인 객체들의 공통체를 만드는 것이 훌륭한 객체지향 설계를 얻을 수 있는 지름길인 것이다.

 

절차지향과 객체지향

수정하기 전 코드의 enter 메서드는 프로세스(Process)이며 Audience, TicketSeller, Bag, TicketOffice는 데이터(Data)이다. 이처럼 프로세스와 데이터를 별도의 모듈에 위치시키는 방식을 절차적 프로그래밍(Procedural Programming)이라고 부른다.

 

절차적 프로그래밍은 우리의 직관에 위배하고, 코드를 읽는 사람과 원할한 의사소통을 하지 못한다. 더 큰 문제는 데이터의 변경으로 인한 영향을 지역적으로 고립시키기가 어렵다는 것이다.

 

변경하기 쉬운 설계는 한 번에 하나의 클래스만 변경할 수 있는 설계다. 절차적 프로그래밍은 프로세스가 필요한 모든 데이터에 의존해야 한다는 근본적인 문제점 때문에 변경에 취약할 수 밖에 없다.

 

해결 방법은 자신의 데이터를 스스로 처리하도록 프로세스의 적절한 단계를 Audience와 TicketSeller로 이동시키는 것이다. 이처럼 데이터와 프로세스가 동일한 모듈 내부에 위치하도록 프로그래밍하는 방식을 객체지향 프로그래밍(Object-Oriented Programming)이라고 부른다.

 

훌륭한 객체지향 설계의 핵심은 캡슐화를 이용해 의존성을 적절히 관리함으로써 객체 사이의 결합도를 낮추는 것이다.

 

책임의 이동

두 방식 사이에 근본적인 차이를 만드는 것은 책임의 이동(shift of responsibility)이다. 여기서 말하는 책임은 기능을 가르키는 객체지향 세계의 용어로 생각하면 된다.

변경 전의 절차적 설계에서는 Theater가 전체적인 작업을 하였다면, 변경 후의 객체지향 설계에서는 각 객체가 자신이 맡은 일을 스스로 처리했다. 다시 말해 Theater에 몰려 있던 책임이 개별 객체로 이동한 것이다. 이것이 바로 책임의 이동이 의미하는 바이다.

 

우리의 코드에서 데이터와 데이터를 사용하는 프로세스가 별도의 객체에 위치하고 있다면 절차적 프로그래밍 방식을 따르고 있을 확률이 높다. 데이터와 데이터를 사용하는 프로세스가 동일한 객체 안에 위치한다면 객체 객체지향 프로그래밍 방식을 따르고 있을 확률이 높다.

 

설계를 어렵게 만드는 것은 의존성이라는 것을 기억하라. 해결 방법은 불필요한 의존성을 제거함으로써 객체 사이의 결합도를 낮추는 것이다. 예제에서는 결합도를 낮추기 위해 캡슐화를 사용하여 객체의 자율성을 높이고 응집도 높은 객체들의 공동체를 창조할 수 있게 되었다.

 

더 개선할 수 있다.

Audience는 스스로 티켓을 구매하고 가방안의 내용물을 직접 관리한다. 하지만 Bag은 과거의 Audience처럼 스스로 자기 자신을 책임지지 않고 Audience에 의해 끌려다니는 수동적인 존재다.

 

Bag을 자율적인 존재로 바꿔보자. 방법은 이전과 동일하게 캡슐화하여 결합도를 낮추면 된다.

 

 

public class Bag {
    private Long amount;
    private Ticket ticket;
    private Invitation invitation;
 
    public Long hold(Ticket ticket) {
        if(hasInvitation()) {
            setTicket(ticket);
            return 0;
        } else {
            setTicket(ticket);
            minusAmount(ticket.getFee());
            return ticket.getFee();
        }
    }
 
    ...
}
 
public class Audience {
    public Long buy(Ticket ticket) {
        return bag.hold(ticket);
    }
}

 

 

TicketSeller 역시 TicketOffice의 자율권을 침해하고 있다.

 

public class TicketOffice {
    public void sellTicketTo(Audience audience) {
        plusAmount(audience.buy(getTicket()));
    }
    ...
}
 
public class TicketSeller {
    public void sellTo(Audience audience) {
        ticketOffice.sellTicketTo(audience));
    }
}

 

 

변경된 코드를 보면 이전에는 없었던 TicketOffice와 Audience 사이에 의존성이 추가되었다. 의존성의 추가는 높은 결합도를 의미하고, 높은 결합도는 변경하기 어려운 설계를 의미한다. TicketOffice의 자율성은 높였지만 전체 설계의 관점에서는 결합도가 상승했다. 트레이드오프이다.

 

이 예제를 통해 우리는 두 가지 사실을 알게 되었다.

1. 어떤 기능을 설계하는 방법은 한 가지 이상일 수 있다.
2. 동일한 기능을 한 가지 이상의 방법으로 설계할 수 있기 때뭉네 결국 설계는 트레이드오프의 사눔ㄹ이다.

어떤 경우에도 모든 사람들을 만족시킬 수 있는 설계를 만들 수는 없다.

 

설계는 균형의 예술이다. 훌륭한 설계는 적절한 트레이드오프의 결과물이라는 사실을 기억해야 한다.

 

 

그래, 거짓말이다!

우리의 코드는 스스로 자신을 책임지는 형태로 변경하였다. 하지만 Theater, Bag, TicketOffice는 실세계에서는 자율적인 아니다. 예를 들어 가방에서 돈을 꺼내는 것은 관람객이지 가방이 아니다. 

 

비록 현실에서는 수동적인 존재라고 하더라도 일단 객체지향의 세계에 들어오면 모든 것이 능동적이고 자율적인 존재로 바뀐다. 레베카 워프스브록(Rebecca Wirfs-Brock)은 이를 의인화(anthropomorphism)라고 불렀다.

 

 

4. 객체지향 설계

 

설계가 왜 필요한가

 

설계란 코드를 배치하는 것이다.

 

설계를 구현과 떨어트려서 이야기하는 것은 불가능하다. 설계는 코드를 작성하는 매 순간 코드를 어떻게 배치할 것인지를 결정하는 과정에서 나온다. 설계는 코드 작성의 일부이며 코드를 작성하지 않고서는 검증할 수 없다.

 

좋은 설계란 오늘 요구하는 기능을 온전히 수행하면서 내일의 변경을 매끄럽게 수용할 수 있는 설계다. 변경을 수용할 수 있는 설계가 중요한 이유는 요구사항이 항상 변경되기 때문이다. 개발을 시작 시점에 모든 요구사항을 수집한다 하더라고 개발이 진행되는 동안 요구사항은 바뀔 수밖에 없다. 요구사항 변경은 필연적으로 코드 수정을 초래하고, 코드 수정은 버그가 발생할 가능성을 높인다. 코드 수정을 회피하려는 가장 큰 원인은 두려움이다. 그리고 그 두려움은 요구사항 변경으로 인해 버그를 추가할지도 모른다는 불확실성에 기인한다.

 

객체지향 설계

우리가 원하는 것은 변경에 유연하게 대응할 수 있는 코드다. 객체지향 프로그래밍은 의존성을 효율적으로 통제할 수 있는 다양한 방법을 제공함으로써 요구사항 변경에 좀 더 수월하게 대응할 수 있는 가능성을 높여준다. 

변경 가능한 코드란 이해하기 쉬운 코드다. 코드 변경시 이해하기 어렵다면 코드를 변경하기가 쉽지 않을 것이다. 

 

객체지향 패러다임은 세상에 존재하는 모든 자율적인 존재처럼 객체 역시 자신의 데이터를 스스로 책임지는 자율적인 존재다. 객체지향은 우리가 세상에 대해 예상하는 방식대로 객체가 행동하리라는 것을 보장함으로써 코드를 좀 더 쉽게 이해할 수 있게 한다. 그러나 단순히 데이터와 프로세스를 객체라는 덩어리 안으로 밀어 넣었다고 해서 변경하기 쉬운 설계를 얻을 수 있는 것은 아니다. 객체지향의 세계에서 애플리케이션은 객체들로 구성되며 애플리케이션의 기능은 객체들 간의 상호작용을 통해 구현된다. 그리고 객체들 사이의 상호작용은 객체 사이에 주고 받는 메시지로 표현된다.