오브젝트 1장 - 객체, 설계(2)

3. 설계 개선하기

 

이전 포스팅에서 설명했던 것을 토대로 변경과 의사소통이라는 문제는 서로 엮여있다.

코드의 의도를 정확하게 파악할 수 있도록 하려면, Audience와 TicketSeller를 변경할 때 Theater도 함께 변경해야 한다.

 

Theater가  Audience와 TicketSeller에 관해 너무 세세한 부분까지 알지 못하도록 해야 한다.

관람객이 스스로 가방 안의 현금과 초대장을 처리하고, 판매원이 스스로 매표소의 티켓과 판매 요금을 다르게 한다면 문제를 해결할 수 있다.

다시 말해서 관람객과 판매원을 자율적인 존재로 만들면 된다.

 

자율성을 높이자

 

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

 

여기서 TicketSeller에서 getTicketOffice메서드가 제거됐다는 사실에 주목하라.

ticketOffice의 가시성이 private이고 접근 가능한 퍼블릭 메서드가 더이상 존재하지 않기 때문에 외부에서 ticketOffice에 더이상 직접 접근할 수 없게 되었다.

 

-> 결론 : ticketOffice에서 티켓을 꺼내거나 판매 요금을 적립하는건 TickketSeller만 할 수 있음
-> Point : 개념적으로나 물리적으로 객체 내부의 세부사항을 감추는 것 : 캡슐화(Encapsulation)

 

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

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

 

Theather은 TicketOffice가 TicketSeller 내부에 존재한다는 사실을 알지 못한다.

단지 TicketSeller가 sellTo()메세지를 이해하고 응답할 수 있다는 사실만 알고 있을 뿐이다.

Theather은 오직 TicketSeller의 인터페이스(Interface)에만 의존한다.

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

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

 

2. TicketSeller에서 Bag에 접근하는 모든 로직을 Audience 내부로 감추기

 

 

Audience는 자신의 가방안에 초대장이 들어있는지 직접 스스로 확인한다. 외부의 제 3자가 자신의 가방을 열어보도록 허용하지 않는다. Audience가 Bag을 직접 처리하기 때문에 외부에서는 더이상 Audience가 Bag을 소유하고 있다는 사실을 알 필요가 없으므로 getBag()메서드를 제거할 수 있고 결과적으로 Bag의 존재를 내부로 캡슐화 할 수 있다.

 

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

 

어떻게 개선한 것인가

 

수정하기 전 : Theater가 Audience와 TicketSeller의 상세한 내부 구현까지 알고 있어야 했다. 따라서 Theater는  Audience와 TicketSeller에 강하게 결합돼 있었고,  Audience와 TicketSeller의 사소한 변경에도 Theater가 영향을 받았다.

 

수정한 후 : Theater는 Audience와 TicketSeller의 내부에 직접 접근하지 않는다. Audience와 TicketSeller가 각자 객체의 자율성을 높이는 방향으로 설계했다.

 

캡슐화와 응집도

 

핵심은 객체 내부의 상태를 캡슐화하고 객체 간에 오직 메세지를 통해서만 상호작용하도록 만드는 것이다.

밀접하게 연관된 작업만 수행하고 연관성 없는 작업은 다른 객체에게 위임하는 객체를 가리켜 응집도(Cohesion)가 높다고 말한다.

💡 자신의 데이터를 스스로 처리하는 자율적인 객체를 만들면 결합도를 낮추고 응집도를 높일 수 있다.
외부의 간선을 최대한 배제하고 메시지를 통해서만 협력하는 자율적인 객체들의 공동체를 만드는 것이 훌륭한 객체지향 설계를 얻을 수 있는 지름길이다.

 

절차지향과 객체지향

 

Audience, TicketSeller, Bag, TicketOffice은 관람객을 입장시키는데 필요한 정보를 제공하고 모든처리는 Theather의 enter메서드 안에 존재했었다.

 

• Theather의 enter 메서드 : 프로세스(Process)
• Audience, TicketSeller, Bag, TicketOffice : 데이터(Data)

 

이처럼 프로세스와 데이터를 별도의 모듈에 위치시키는 것을 절차 지향적 프로그래밍(Procedural Programming)이라고 부른다.

 

위에 있는 그림 1.2는 절차적 프로그래밍 방식으로 작성된 코드의 전형적인 의존성 구조를 보여준다.

모든 처리가 하나의 클래스 안에 위치하고 나머지 클래스는 단지 데이터의 역할만 수행하기 때문이다.

 

절차적 프로그래밍은 우리의 직관에 위배된다. 또한 데이터의 변경으로 인한 영향을 지역적으로 고립시키기 어렵다. 변경은 버그를 부르고 버그에 대한 두려움은 코드를 변경하기 어렵게 만든다. 절차적 프로그래밍의 세상은 변경하기 어려운 코드를 양상하는 경향이 있다.

 

수정 후는 데이터와 프로세스가 동일한 모듈 내부에 위치하도록 프로그래밍 하는 방식을 객체 지향 프로그래밍(Object-Oriented Programming)이라고 한다.

 

그림 1.6에서 Theather은 오직 TicketSeller에만 의존한다. 물론 TicketSeller입장에서는 Audience에 대한 의존성이 추가됐지만 적절한 트레이드오프의 결과이다.

 

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

 

책임의 이동

 

절차지향과 객체지향의 근본적인 차이를 만드는 것은 책임의 이동(shift of responsibility)이다.

 

위의 그림에서 보면 작업흐름이 주로 Theather에 의해 제어된다는 사실을 알 수 있는데, 객체 지향의 세계에서 표현하면 책임이 Theather에 집중되어 있는 것이다.

하지만 위의 그림을 보면 제어 흐름이 각 객체에 적절하게 분산돼 있음을 알 수 있다. 즉, 하나의 기능을 완성하는데 필요한 책임이 여러 객체에 걸쳐 분산돼 있는 것이다.

 

적절한 객체에 적절한 책임을 할당해야 한다.

• TicketSeller의 책임 : 티겟을 판매하는 것
• Audience의 책임 : 티겟을 사는 것
• Theather의 책임 : 관람객을 입장시키는 것

💡설계를 어렵게 만드는것은 의존성이라는 것을 기억해야 한다. 불필요한 의존성을 제거함으로써 객체 사이의 결합도를 낮춰야 한다. 불필요한 세부사항을 캡슐화하는 자율적인 객체들이 낮은 결합도와 높은 응집도를 가지고 협력하도록 최소한의 의존성만을 남기는 것이 훌륭한 객체 지향 설계이다.

 

 

좀 더 개선해보자

 

1. Audience는 자율적인 존재이지만, Bag은 과거의 Audience처럼 스스로 자기 자신을 책임지지 않고 Audience에 의해 끌려다니는 수동적 존재이다.

 

Bag의 내부 상태에 접근하는 모든 Bag안으로 캡슐화해서 결합도를 낮추면 된다.

package chapter1.theater;

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

 

 

2. TicketSeller 역시 TicketOffice의 자율권을 침해한다. TicketSeller는 TicketOffice에 있는 Ticket을 마음대로 꺼내서 자기 멋대로 Audience한테 팔고 에게 받은 돈을 마음대로 TicketOffice에 넣는다.

package chapter1.theater;

public class TicketSeller {
    private TicketOffice ticketOffice;

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

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

 

 

하지만 이 변경은 기존에 없었던 TicketOffice와 Audience사이에 의존성이 추가되었기 때문에 만족스럽지 못한 코드이다.

 

🚩 이러한 트레이드 오프 시점에서 어떤 것을 우선해야 하는가?

 

개발팀의 토론 결과 TicketOffice의 자율성보다 Audience에 대한 결합도를 낮추는 것이 더 중요하다는 결론이 나왔다.

 

1. 어떤 기능을 설계하는 방법은 한 가지 이상일 수 있다.

2. 동일한 기능을 한 가지 이상의 방법으로 설계할 수 있기 때문에 결국 설계는 트레이드 오프의 산물이다. 어떤 경우에도 모든 사람들을 만족 시킬 수 있는 설계를 만들 수 없다.

 

 

그래, 거짓말이다!

 

앞에서 실생활의 관람객과 판매자가 스스로 자신의 일을 처리하기 때문에 코드에서의 Audience와 TicketSeller 역시 스스로 자신을 책임져야 했다고 말했던 것을 기억하는가? 이것은 우리가 세상을 바라보는 직관과도 일치한다. 직관에 따르는 코드는 이해하기가 더 쉬운 경향이 있다.

 

그러나 Theater, Bag, TicketOffice는 실세계에서 자율적인 존재가 아니다.

소극장에 관람객이 입장하기 위해서 누군가가 소극장의 문을 열고 입장을 허가해줘야 한다.

가방에서 돈을 꺼내는 것은 관람객이지 가방이 아니다. 판매원이 매표소에 없는데도 티켓이 저절로 관람객에게 전달되지 않을 것이다.

 

그럼에도 우리는  Theater, Bag, TicketOffice를 생물처럼 다뤘다. 비록 현실에서는 수동적인 존재라고 할지라도 일단 객체지향의 세계에 들어오면 모든 것이 능동적이고 자율적인 존재로 바뀐다.

 

레베카 워프스브록은 이처럼 능동적이고 자율적인 존재로 소프트웨어 객체를 설계하는 원칙을 의인화(anthropomorphism)이라고 부른다.

 

4. 객체지향 설계

 

설계가 왜 필요한가

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

어떤 사람들은 설계가 코드를 작성하는 것보다 높은 차원의 창조적인 행위라고 생각한다. 하지만 설계를 구현과 떨어트려서 이야기하는 것은 불가능하다. 설계는 코드를 작성하는 매 순간 코드를 어떻게 배치할 것인지를 결정하는 과정에서 나온다. 설계는 코드 작성의 일부이며 코드를 작성하지 않고서는 검증할 수 없다.

 

예제코드를 보면 변경 전과 변경 후 코드가 모두 소극장에 방문한 관람객들을 입장시키는 작업을 성공적으로 수행한다.

하지만 코드를 배치하는 방법은 완전 다르다! 첫 번째 코드에서는 데이터와 프로세스를 나누어 별도의 클래스에 배치했지만, 두 번째 코드에서는 필요한 데이터를 보유한 클래스 안에 프로세스를 함께 배치했다. 두 프로그램은 서로 다른 설계를 가진 것이다.

 

🚩 좋은 설계란?

 

1. 우리는 오늘 완성해야 하는 기능을 구현하는 코드를 짜야 하는 동시에 내일 쉽게 변경할 수 있는 코드를 짜야 한다

2. 오늘 요구하는 기능을 온전히 수행하면서 내일의 변경을 매끄럽게 수용할 수 있는 설계다.

 

변경을 수용할 수 있는 설계가 중요한 이유는 요구사항이 항상 변경되기 때문이다. 개발을 시작하는 시점에 구현에 필요한 모든 요구사항을 수집하는 것은 불가능에 가깝다. 모든 요구사항을 수집할 수 있다고 가정하더라도 개발이 진행되는 동안 요구사항은 바뀔 수 밖에 없다.

 

그리고 변경을 수용할 수 있는 설계가 중요한 또 다른 이유는 코드를 변경할 때 버그가 추가될 가능성이 높기 때문이다.

코드를 수정하지 않는다면 버그는 발생하지 않는다. 하지만 요구사항 변경은 필연적으로 코드 수정을 초래하고, 코드 수정은 버그가 발생하라 가능성을 높인다. 버그의 가장 큰 문제점은 코드를 수정하려는 의지를 꺾는다. 

 

객체지향 설계

 

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

 

단순히 데이터와 프로세스를 객체라는 덩어리 안으로 밀어 넣는다고 해서 변경하기 쉬운 설계를 얻을 수 있는 것은 아니다. 객체지향의 세계에서 애플리케이션은 객체들로 구성되며 애플리케이션의 기능은 객체들 간의 상호작용을 통해 구현된다.

그리고 객체들 사이의 상호작용은 객체 사이에 주고 받는 메세지로 표현된다.

 

TicketSeller는 Audience에 buy메시지를 전송하고, TicketSeller는 Bag에 minusAmont메시지를 전송한다

 

이처럼 애플리케이션의 기능으 구현하기 위해 객체들이 협력하는 과정 속에서 객체들은 다른 객체에 의존하게 된다.

TicketSeller가 Audience에 메시지를 전송하기 위이해 Audience에 대해 알고 있어야 한다.

메시지를 전송하기 위한 이런 지식이 두 객체를 결합시키고 이 결합이 객체 사이의 의존성을 만든다.

 

💡 훌륭한 객체지향 설계란 협력하는 객체 사이의 의존성을 적절하게 관리하는 설계다.
세상에 엮인 것이 많은 사람일수록 변하기 어려운 것처럼 객체가 시행되는 주변 환경에 강하게 결합될수록 변경하기 어려워진다.

데이터와 프로세스를 하나의 덩어리로 모으는 것은 훌륭한 객체지향 설계로 가는 첫걸음일 뿐이다.
진정한 객체지향 설계로 나아가는 길은 협력하는 객체들 사이의 의존성을 적절하게 조절함으로써 변경에 용이한 설계를 만드는 것이다.

 

 

코드 확인할 수 있는 Github 링크

GitHub - codesejin/OOP-Object: [오브젝트] - 코드로 이해하는 객체지향 설계