오브젝트 - 객체, 설계

DevSeoRex·2022년 12월 10일

객체지향 설계 오브젝트 오브젝트 코드로 이해하는 객체지향 설계 조영호 조영호 오브젝트

🧐 왜 하필 객체지향 설계책을..?

요즘 관심있는 주제가 하나 있었습니다.
그것은 바로 좋은 코드는 어떤 코드가 좋은 코드일까?
또 좋은 코드를 만들려면 어떤 노력을 해야할까 하는 것들이 가장 큰 관심사였습니다.

좋은 코드?
좋은 코드라 하면 좋은 코드의 정의는 무엇일까 많은 고민을 해보았습니다.

코드를 작성하기전에 어떤 일부터 해야 할까? 코드를 작성하려고 키보드위에 손부터 두는 저의 모습을 떠올리면서 좋은 코드는 좋은 설계에서 나오지 않을까 하는 생각에 이 책을 고르게 되었습니다.

첫 번째 책은 현재 읽고 있는
오브젝트 : 코드로 이해하는 객체지향 설계를 구입하였습니다.

이런 좋은 책이 있었다니!

프로젝트를 진행하면서 데이터 모델링에 대해서 공부를 하고, 직접 팀원들과 테이블 설계를 하였는데 이 과정에서 애플리케이션의 요구사항이 바뀔때마다 컬럼이 수정되야 하고, 심한 경우 관계를 끊거나 관계를 추가한 외래키의 변동을 가져오는 경우가 많았습니다.

그래서 왜 이런 문제가 발생하게 될까..? 이런 일을 처음부터 방지할 방법은 없었을까?
나름 설계책을 한권 읽고, 스터디를 진행하고 하는 설계였지만 처음 해보는 설계에 교과서에 나온대로
개념 모델링 -> 논리 모델링 -> 물리 모델링의 순으로 설계를 진행하며 관계를 정립할때도 크로스 체크를 진행하며 많은 케이스를 따져보기도 했습니다.

처음 부터 설계를 잘했더라면.. 😭

물론 가장 좋은 것은 설계를 처음부터 변경이나 수정에 유연히 대처할 수 있도록 하면 좋았을거라 생각하지만 처음부터 완벽한 것은 없기에 약간의 아쉬움이 남았다.

최근에 Spring Framework를 사용하며 ORM을 이끄는 선두주자인 JPA를 공부하다 보니 더 많은 관심이 생기게 되었는데, ORM에서도 중요한 것이 관계형 데이터베이스와 객체간의 패러다임 차이를 극복하는 것이였고, 이를 극복하기 위해 JPA는 어떤 고민을 했는지에 대해서 배웠다.

처음에 한창 배우고 있을때는 작동만 하면 신기하고, 그저 코드를 작성하는 것에 급급했다면 아직도 병아리지만 TDD와 DDD등 더 좋은 코드 작성을 위한 설계에 대한 고민을 시작하게 되어서 이 책을 접하게 되었다.

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

예를 들어, 작은 소극장이 있다고 해보겠습니다.
작은 소극장의 홍보를 하기위해 이벤트를 기획하게 되었다고 가정해보겠습니다. 추첨을 통해 선정된 관램객에게 공연을 무료로 관람할 수 있는 초대장을 발송하는 것을 기획하게 되었죠.

여기서 애플리케이션을 개발하는 입장에서는 요구 사항이 생기게 됩니다.

이벤트에 당첨된 관람객과 그렇지 못한 관람객은 다른 방식으로 입장시켜야 한다.
이벤트에 당첨되지 않은 관람객은 티켓을 구매해야만 입장할 수 있다.
이벤트에 당첨된 관람객은 티켓을 구매하지 않아도 입장할 수 있다.

여기서 핵심은 관람객이 입장에 시도할 때, 이벤트 당첨 여부를 확인해야 하고 이벤트 당첨자가 아닐 경우에는 티켓을 판매한 후에 입장시켜야 한다는 것입니다.

먼저, 이벤트 당첨자에게 발송되는 초대장을 구현한 Invitation 클래스를 작성하고, 모든 관람객은 티켓을 소지하고 있어야 하기 때문에 Ticket 클래스를 작성하겠습니다.

// Invitation 클래스
public class Invitation {
	private LocalDateTime when;
}

// Ticket 클래스
public class Ticket {
	private Long fee;
    
    public Long getFree() {
    	return fee;
    }
}

영화를 보러오는 관람객 클래스를 작성하기에 앞서 관람객에 대한 요구사항을 정의해보겠습니다.

관람객 중 이벤트 당첨자는 티켓으로 교환할 초대장을 가지고 있다.
이벤트에 당첨되지 않은 관람객은 티켓을 구매할 수 있는 현금을 보유하고 있다.
관람객이 가지고 올 수 있는 소지품은 초대장,현금,티켓 세 가지로 제한한다.
관람객은 소지품을 보관할 용도로 가방을 들고 올 수 있다.

관람객이 소지품을 보관할 수 있는 Bag 클래스를 아래와 같이 작성해 보겠습니다.
Bag 클래스가 가지고 있는 인스턴스 변수들과 메서드들은 아래와 같습니다.

현금(amount), 초대장(Invitation), 티켓(Ticket)
hasInvitation( ) : 초대장 보유 여부를 확인하는 메서드
hasTicket( ) : 티켓 소유 여부를 판단하는 메서드
plusAmount( ) : 현금을 증가시키는 메서드
minusAmount( ) : 현금을 감소시키는 메서드
setTicket( ) : 초대장을 티켓으로 교환하는 메서드

// Bag 클래스
public class Bag {
    private Long amount;
    private Invitation invitation;
    private Ticket ticket;

    public boolean hasInvitation() {
        return ticket != null;
    }

    public boolean hasTicket() {
        return ticket != null;
    }

    public void setTicket(Ticket ticket) {
        this.ticket = ticket;
    }

    public void minusAmount(Long amount) {
        this.amount -= amount;
    }

    public void plusAmount(Long amount) {
        this.amount += amount;
    }

}

이벤트에 당첨된 관람객의 가방 안에는 현금과 초대장이 들어있지만, 이벤트에 당첨되지 않은 관람객은 초대장을 가방에 가지고 있지 않을 것입니다.
그렇다면, Bag 인스턴스의 상태는 현금과 초대장을 함께 보관하거나, 초대장 없이 현금만 보관하는 두 가지 상태 중 하나라고 할 수 있겠습니다.

Bag의 인스턴스를 생성하는 시점에 이 제약을 강제할 수 있도록 생성자를 만들어 보겠습니다.

// Bag의 인스턴스 생성하는 시점에 제약을 강제하는 생성자 생성

    public Bag(long amount) {
        this(null, amount);
    }

    public Bag(Invitation invitation, long amount) {
        this.invitation = invitation;
        this.amount = amount;
    }

위에서 요구사항을 정의한대로, 관람객은 소지품을 보관하기 위한 가방을 소지할 수 있습니다.
관람객을 정의한 Audience 클래스를 작성해보겠습니다.

// Audience 클래스
public class Audience {
    private Bag bag;

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

    public Bag getBag() {
        return bag;
    }
}

관람객이 소극장에 입장하려면 매표소에서 초대장을 티켓으로 교환하거나 구매해야 한다는 요구사항이 있습니다. 따라서, 매표소에는 관람객에게 판매할 티켓과 티켓의 판매 금액이 보관돼 있어야 합니다.

매표소를 구현하기 위해 TicketOffice 클래스를 작성하기 전에 이 클래스가 가지고 있는 인스턴스 변수와 메서드들을 정의해 보겠습니다.

티켓의 목록(tickets), 판매금액(amount)
getTicket( ) : 티켓을 판매하는 메서드
plusAmount( ) : 판매금액을 더하는 메서드
minusAmount( ) : 판매금액을 차감하는 메서드

// TicketOffice 클래스
public class TicketOffice {

    private Long amount;
    private List<Ticket> tickets = new ArrayList<>();

    public TicketOffice(Long amount, Ticket ... tickets) {
        this.amount = amount;
        this.tickets.addAll(Arrays.asList(tickets));
    }

    public Ticket getTicket() {
        return tickets.remove(0);
    }

    public void minusAmount(Long amount) {
        this.amount -= amount;
    }

    public void plusAmount(Long amount) {
        this.amount += amount;
    }
}

티켓을 판매하는 판매원은 매표소에서 초대장을 티켓으로 교환해주거나 티켓을 판매하는 역할을 합니다. 판매원을 구현한 TicketSeller 클래스는 자신이 일하는 매표소(ticketOffice)를 알고 있어야 한다는 요구사항이 있습니다.

// TicketSeller 클래스
public class TicketSeller {

    private TicketOffice ticketOffice;

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

    public TicketOffice getTicketOffice() {
        return ticketOffice;
    }
}

이제 마지막으로 소극장을 구현하는 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);
        }
    }
}

이렇게 작성한 클래스들이 작동하는 시나리오는 아래와 같습니다.

소극장은 관람객의 가방 안에 초대장이 들어 있는지 확인한다.
초대장이 들어있다면 판매원에게서 받은 티켓을 관람객의 가방안에 넣어준다.
가방안에 티켓이 없다면 티켓을 판매한다.
티켓을 판매했다면 소극장은 관람객의 가방에서 티켓 금액만큼을 차감한다.
소극장은 티켓을 판매해 얻은 금액을 매표소에 증가시킨다.
소극장은 관람객의 가방 안에 티켓을 넣어주고 극장에 입장시킨다.

이렇게 작성된 프로그램은 의도한대로 동작하게 됩니다.

애써 작성한 프로그램에 문제가..? 🥺

위에서 애써 만든 코드들에 문제가 있다면 어떨까요?
간단한 로직이지만 이 로직을 작성하기 위해 꽤나 많은 노력을 하고 시간을 투자했을 것이기 때문에 더 슬플 겁니다 😱

안타깝지만 위에서 만든 프로그램은 몇 가지 문제점을 가지고 있습니다.

~~기껏 다 만든 줄 알았는데..~~

실제로 업무를 하며 애플리케이션을 개발할때 이런 문제점을 생각하지 않고 코드를 작성해, 요구사항 수정에 유연히 대처하지 못하는 프로그램을 만들지 않도록 설계를 배우는 것이기 때문에 지금부터는 위 프로그램의 문제점은 무엇인지 알아보고 객체지향적인 설계로 변경해 보겠습니다.

그렇다면 무엇이 문제일까 ❓

처음에 이 프로그램을 작성하고 갑자기 이 프로그램에는 작은 문제들이 몇가지 있다는 저자의 말에 동감하지 못했습니다.
왜냐하면 ~~저는 아직도 작성한 프로그램이 그저 동작만 하면 되는 그런 사람에 머물고 있기 때문이겠죠..(슬프다)~~

이 파트를 읽으면서 코드를 수정하고 보니 상당히 많은 부분들이 잘못되어 있었다는 것도 알게 되었습니다. 지금부터 한번 수정해보도록 하겠습니다.

소프트웨어 모듈이 가져야 하는 세 가지 기능

로버트 마틴(Robert C. Martin)은 저서를 통해 소프트웨어 모듈이 가져야 하는 세가지 기능에 관해 설명했습니다. 여기서 말하는 모듈은 크기에 상관 없이 클래스나 패키지, 라이브러리와 같이 프로그램을 구성하는 임의의 요소를 의미합니다.

실행 중에 제대로 동작해야 한다.
변경을 위해 존재하는 것이다. 대부분의 모듈은 생명주기 동안 변경되기 때문에 간단한 작업만으로도 변경이 가능해야 한다.
- 변경하기 어려운 모듈은 제대로 동작하더라도 개선해야 한다.
코드를 읽는 사람과 의사소통 해야한다. 모듈은 특별한 훈련 없이도 개발자가 쉽게 읽고 이해할 수 있어야 한다.

로버트 마틴이 정의한 세가지 기능에 따라 위에서 작성한 프로그램을 봤을때, 제대로 동작해야 한다는 제약은 만족시키지만, 변경 용이성과 읽는 사람과의 의사소통이라는 목적은 만족시키지 못하고 있습니다.

⛔️ 예상을 빗나가는 코드

현재 위에서 작성한 클래스들의 문제는 관람객과 판매원이 소극장의 통제를 받는 수동적인 존재라는 점입니다.

이런 문제점이 어디서 나오는지 풀어보겠습니다.

관람객의 입장에서 소극장이라는 제3자가 초대장을 확인하기 위해 관람객의 가방을 마음대로 열어 본다.
판매원의 입장에서 소극장이 허락도 없이 매표소에 보관 중인 티켓과 현금에 마음대로 접근할 수 있다.
판매원의 입장에서는 매표소 안에 가만히 앉아 티켓이 하나씩 사라지고 돈이 저절로 쌓이는 광경을 두손놓고 보는 것과 같다.

위 코드는 우리의 일반적인 상식과는 벗어나고 있습니다. 이해 가능한 코드란 그 동작이 우리의 예상에서 크게 벗어나지 않아야 하기 때문입니다.

보통 일반적인 상식에서는 관람객이 초대장이 있는지의 여부를 판매원에게 확인을 시켜주고, 판매원은 관람객이 초대장이 없다면 티켓을 판매한뒤에 티켓을 건네준다음 판매한 금액을 매표소에 보관하고 극장에 입장시켜주는 것이 일반적이라고 할 수 있습니다.

위 문제를 한마디로 축약한다면

📣 하나의 객체인 클래스가 각자의 역할(책임)을 다하지 못하고 수동적으로 다른 객체에 의해 동작당하고 있다는 것이 문제입니다.

위 코드를 이해하기 어려운 또 다른 이유가 있는데, 이 코드를 이해하기 위해서는 여러가지 세부적인 내용들을 한꺼번에 기억하고 있어야 한다는 점입니다.

Theater의 enter 메서드를 이해하기 위해서는 Audience가 Bag을 가지고 있고, Bag 안에는 현금과 티켓이 들어 있으며 TicketSeller가 TicketOffice에서 티켓을 판매하고, TicketOffice안에 돈과 티켓이 보관되어 있다는 모든 사실을 동시에 기억하고 있어야 합니다.

enter 메서드의 이해를 위해 풀어쓴 설명만 봐도 이미 머리가 어질어질 해집니다.

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

하지만 위의 문제도 큰 문제같지만 가장 큰 문제는 Audience와 TicketSeller를 변경할 경우 Theater도 함께 변경해야 한다는 사실입니다.

💣 변경에 취약한 코드

위에서 작성한 프로그램은 관람객이 현금과 초대장을 보관하기 위해 항상 가방을 들고 다닌다고 가정하고 작성되었습니다.
만약에 요구사항이 변동되어 관람객이 가방을 들고 있지 않다고 한다면?
관람객이 현금이 아니라 신용카드를 이용해서 결제한다면?
이런 가정이 깨지는 순간 모든 코드가 일시에 흔들리게 됩니다.

관람객이 가방을 들고 있다는 요구사항이 변경되었다고 하면 얼마나 많은 부분이 수정되야 할까요?
관람객과 가방에 대한 부분만 간단히 수정하면 끝날것 같지만 위에서 작성한 클래스는 그렇지 못합니다.

Audience 클래스에서 Bag을 제거하고, Audience의 Bag에 직접 접근하는 Theater의 enter 메서드 역시 수정해야 합니다.
Theater는 관람객이 가방을 들고 있고 판매원이 매표소에서만 티켓을 판매한다는 지나치게 세부적인 사실에 의존해서 동작하기 때문에 문제가 발생합니다.

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

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

객체지향 설계는 서로 의존하면서 협력하는 객체들의 공동체를 구축하는데 의미가 있습니다.

🔑 우리의 목표는 애플리케이션의 기능을 구현하는 데 필요한 최소한의 의존성만 유지하고 불필요한 의존성을 제거하는 것입니다.

객체 사이의 의존성이 과한 경우를 가리켜 결합도(coupling)이 높다고 말합니다.
반대로 객체들이 합리적인 수준으로 의존할 경우에는 결합도가 낮다고 합니다.
결합도는 의존성과 관련돼 있기 때문에 결합도 역시 변경과 관련이 있다고 말합니다. 두 객체 사이에 결합도가 높으면 높을수록 함께 변경될 확률도 높아지기 때문입니다.

📌 설계의 목표는 객체 사이의 결합도를 낮춰 변경이 용이한 설계를 만드는 것이어야 합니다.

설계 개선하기

위에서 작성한 프로그램의 코드의 문제점은 Theater가 관람객의 가방과 판매원의 매표소에 직접 접근하기 때문입니다.
일반적으로 우리는 관람객과 판매원이 자신의 일을 스스로 처리해야 한다는 생각을 가지고 있습니다.
현재 Theater가 관람객의 가방과 판매원의 매표소에 직접 접근한다는 것은 Theater가 Audience와 TicketSeller에 결합된다는 것을 의미합니다.

이 문제를 어떻게 해결할 수 있을까요 ❓
해결 방법은 의외로 간단합니다. Theater가 Audience와 TicketSeller에 관해 너무 세세한 부분까지 알지 못하도록 정보를 차단하면 됩니다.

이렇게 말하면 굉장히 추상적이지만 풀어쓴다면
관람객이 스스로 가방 안의 현금과 초대장을 처리하고 판매원이 스스로 매표소의 티켓과 판매 요금을 다루게 한다는 이야기 입니다.

즉, 관람객과 판매원을 자율적인 존재로 만들면 되는 것입니다.

자율성을 높이기

관람객과 판매원을 자율적인 존재로 바꿔가는 과정에 대해서 살펴보겠습니다.

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

TicketSeller에 sellTo( ) 메서드를 추가하고, Theater에 있는 로직을 이 메서드로 옮겨 보겠습니다.

// TicketSeller 클래스 - 변경 후
public class TicketSeller {

    private TicketOffice ticketOffice;

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

    public void sellTo(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 클래스 - 변경 후
public class Theater {

    private TicketSeller ticketSeller;

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

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

변경된 점들을 정리하면 아래와 같을 것입니다.

ticketOffice의 가시성이 private이고 접근 가능한 퍼블릭 메서드가 더 이상 존재하지 않기 때문에 외부에서는 ticketOffice에 직접 접근이 불가능하다.
TicketSeller는 ticketOffice에서 티켓을 꺼내거나 판매 요금을 적립하는 일을 스스로 수행할 수 밖에 없다.

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

캡슐화의 목적은 변경하기 쉬운 객체를 만드는 것입니다.
캡슐화를 통해 객체 내부로의 접근을 제한함으로서, 객체와 객체의 결합도를 낮출 수 있기에 캡슐화를 하는 것입니다.

위와 같이 코드를 변경함으로서, Theater는 오직 TicketSeller의 인터페이스에만 의존합니다.
TicketSeller가 내부에 TicketOffice 인스턴스를 포함하고 있다는 사실은 구현의 영역에 속합니다.

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

✍ Step 2 Audience의 캡슐화를 개선하기
현재 TicketSeller는 Audience의 getBag( ) 메서드를 호출해서 Audience 내부의 Bag 인스턴스에 직접 접근합니다.
Bag 인스턴스에 접근하는 객체가 Theater에서 TicketSeller로 바뀌었을 뿐, Audience는 여전히 자율적인 존재라고 보긴 어렵습니다.

Bag에 접근하는 로직을 모두 Audience 내부로 감추기 위해 Audience에 buy( ) 메서드를 추가해 보겠습니다.

// Audience 클래스 - 변경 후
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();
        }
    }
}

// TicketSeller - 변경 후
public class TicketSeller {

    private TicketOffice ticketOffice;

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

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

이렇게 코드를 변경하면 무엇이 변경 되었을까요?

Audience는 자신의 가방 안에 초대장이 들어있는지를 스스로 확인한다. 즉, 외부의 제3자가 더 이상 자신의 가방을 열어보는 것을 허용하지 않는다.
Audience가 Bag을 직접 처리하기 때문에 외부에서는 더 이상 Audience가 Bag을 소유하고 있다는 사실을 알 필요가 없다.
내부 구현이 캡슐화됐으므로 Audience를 수정하더라도 TicketSeller에는 영향을 미치지 않는다.

무엇이 개선 되었는가?

수정된 Audience와 TicketSeller을 보면 자신이 가지고 있는 소지품을 스스로 관리합니다.
이것은 일반적인 우리의 예상과도 정확히 맞아 떨어집니다. 읽는 사람과의 의사소통이라는 관점에서 이 코드는 확실히 개선되었다고 보여집니다.

더 중요한 점은 Audience나 TicketSeller의 내부 구현을 변경하더라도 Theater를 함께 변경할 필요가 없어졌다는 것입니다. 변경은 Audience와 TicketSeller 내부만으로 제한됩니다.

위에서 수정된 코드는 변경 용이성의 측면에서도 확실히 개선되었다고 할 수 있습니다.

어떻게 개선을 이뤄 냈을까?

한마디로 축약하면 자기 자신의 문제를 스스로 해결하도록 코드를 변경한 것입니다.
코드를 수정한 후에는 Audience나 TicketSeller의 내부에 직접 접근하지 않습니다.
관람객은 가방 내부의 내용물을 확인 & 추가 & 삭제하는 작업을 스스로 처리하며 외부의 누군가에게 가방을 열어보지 못하도록 합니다.

자기 자신의 문제를 스스로 해결하도록 코드를 변경함으로서 객체의 자율성을 높인 결과, 이해하기 쉽고 유연한 설계를 얻을 수 있게 되었습니다.

캡슐화와 응집도

핵심은 객체 내부의 상태를 캡슐화하고 객체 간에 오직 메시지를 통해서만 상호작용하도록 만드는 것입니다.
밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 위임하는 객체를 가리켜 응집도(cohesion)가 높다고 말합니다.

객체의 응집도를 높이기 위해서는 객체 스스로 자신의 데이터를 책임지게 해야 합니다.
외부의 간섭을 최대한 배제하고 메시지를 통해서만 협력하는 자율적인 객체들의 공동체를 만드는 것이 훌륭한 객체지향 설계를 얻을 수 있는 지름길 입니다.

절차지향 vs 객체지향

수정하기 전의 코드에서는 Audience, TicketSeller, Bag, TicketOffice는 관람객을 입장시키는 데 필요한 정보만을 제공하고 모든 처리는 Theater의 enter( ) 메서드 안에 존재했습니다.

이 관점에서 Theater의 enter( ) 메서드는 프로세스(Process)이며, Audience, TicketSeller, Bag, TicketOffice는 데이터(Data)입니다.
위와 같이 프로세스와 데이터를 별도의 모듈에 위치시키는 방식을 절차적 프로그래밍(Procedural Programming)이라고 부릅니다.

절차적 프로그래밍의 세상에서는 데이터의 변경으로 인한 영향을 지역적으로 고립시키기가 어렵습니다.

따라서 자신의 데이터를 스스로 처리하도록 프로세스의 적절한 단계를 Audience와 TicketSeller로 이동시켰습니다.
위와 같이 데이터와 프로세스가 동일한 모듈 내부에 위치하도록 프로그래밍 하는 방식을 객체지향 프로그래밍(Object-Oriented-Programming)이라고 부릅니다.

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

책임의 이동(shift of responsibility)

위에서 살펴본 두 방식의 근본적인 차이를 만드는 것은 책임의 이동입니다.
변경 전의 코드는 주로 Theater에 의해 제어된다는 사실을 알 수 있습니다. 객체지향 세계의 용어를 사용해서 표현하자만 '책임이 Theater에 집중되어 있다.' 라고 표현할 수 있습니다.

코드를 변경한 후에는 객체지향 설계에 의해 각 객체가 자신이 맡은 일을 스스로 처리하게 되었습니다.
Theater에 몰려 있던 책임이 개별 객체로 이동한 것입니다. 이것이 책임의 이동이 의미하는 것입니다.

객체지향 설계에서는 독재자가 존재하지 않습니다. 각 객체에 책임이 적절히 분배되고, 자신을 스스로 책임집니다.

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

결국 객체지향 설계의 핵심은 객체가 어떤 데이터를 가지느냐보다는 객체에 어떤 책임을 할당할 것이냐에 초점을 맞추고 적절한 객체에 적절한 책임을 할당하는 것입니다.

설계를 어렵게 만드는 가장 큰 주범은 의존성입니다. 객체 사이의 결합도를 낮춰서 의존성때문에 생기는 문제를 해결할 수 있었습니다. 불필요한 세부사항을 객체 내부로 캡슐화하여 객체의 자율성을 높이고 응집도 높은 객체들의 공동체를 창조할 수 있게 되었습니다.

📍 자율적인 객체들이 낮은 결합도와 높은 응집도를 가지고 협력하도록 최소한의 의존성만을 남기는 것이 휼륭한 객체지향 설계입니다.

Trade-Off의 시점이 왔다!

지금껏 수정을 통해 변경에 용이한 좋은 코드를 작성했지만, 아직 더 개선할 수 있는 점들이 남아있습니다.
첫째는, Bag은 아직도 Audience에 의해 끌려다니는 수동적인 존재로 남아있다는 점입니다.
둘째는, TicketSeller 역시 TicketOffice의 자율권을 침해한다는 점입니다.
먼저, 수정을 통해 Bag을 자율적인 존재로 바꾸어 보겠습니다.

🔆 Step 1 Bag을 자율적인 존재로 바꾸기

// Bag 클래스
public class Bag {

    private Long amount;
    private Invitation invitation;
    private Ticket ticket;

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

    private boolean hasInvitation() {
        return ticket != null;
    }

    private void setTicket(Ticket ticket) {
        this.ticket = ticket;
    }

    private void minusAmount(Long amount) {
        this.amount -= amount;
    }

}

Bag의 구현을 캡슐화시켰으므로 Audience를 Bag의 구현이 아닌 인터페이스에만 의존하도록 수정해보겠습니다.

// Audience 클래스 - 변경 후
public class Audience {

    private Bag bag;

    public Audience(Bag bag) {
        this.bag = bag;
    }
    public Long buy(Ticket ticket) {
        return bag.hold(ticket);
    }
}

📢 Step 2 TicketSeller 로부터 TicketOffice의 자율권 찾아주기
현재의 TicketSeller는 TicketOffice에 있는 Ticket을 마음대로 꺼내고 자기 마음대로 Audience에게 팔고 Audience에게 받은 돈을 마음대로 넣어버립니다.

// TicketOffice 클래스 - 개선 후
public class TicketOffice {

    private Long amount;
    private List<Ticket> tickets = new ArrayList<>();

    public TicketOffice(Long amount, Ticket... tickets) {
        this.amount = amount;
        this.tickets.addAll(Arrays.asList(tickets));
    }

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

    private Ticket getTicket() {
        return tickets.remove(0);
    }

    private void plusAmount(Long amount) {
        this.amount += amount;
    }
}

// TicketSeller 클래스 - 개선 후
public class TicketSeller {

    private TicketOffice ticketOffice;

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

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

TicketSeller는 TicketOffice의 sellTicketTo( ) 메서드를 호출함으로써 원하는 목적을 달성할 수 있게 되었습니다.
TicketSeller 역시 TicketOffice의 구현이 아닌 인터페이스에만 의존하게 되었습니다.

설계가 깔끔한게 떨어질 것 같지만, 우리에게는 한가지 안좋은 소식이 들려옵니다.
그건 바로 TicketOffice와 Audience 사이에 의존성이 추가 되었다는 소식입니다. 변경 전에는 TicketOffice가 Audience에 대해 알지 못했지만, 변경 후에는 TicketOffice가 Audience에게 직접 티켓을 판매하기 때문에 Audience에 대해 알고 있어야 합니다.

TicketOffice의 자율성은 높였지만 전체 설계의 관점에서는 결합도가 상승하게 되었습니다.
이제 어떻게 풀어나가야 할까요 ?

이렇게 Trade-Off의 시점이 오게 된 것 입니다.
Trade-Off란 쉽게 말해 하나의 이익을 얻으면 다른 하나를 잃게 되는 상황을 말합니다.

어떤 기능을 설계하는 방법은 한가지 이상일 수 있고, 동일한 기능을 한가지 이상의 방법을 설계할 수 있기 때문에 설계는 Trade-Off의 산물이라고 볼 수 있습니다.

🎓 결국 설계는 균형을 맞춰가는 것이 중요합니다.

현실과는 조금 다른 객체지향의 세상

판매원과 관람객은 현실에서도 생물이다 살아 움직이고 본인이 스스로 무언가를 처리할 수 있습니다.
하지만 소극장과 가방, 매표소는 어떠한가요?

소극장에 관람객이 입장하려면 누군가 소극장의 문을 열어주어야 합니다. 가방에서 돈을 꺼내는 것도 관람객이지 가방 스스로 열리는 것도 아닙니다. 판매원이 매표소에 없는데 티켓이 저절로 관램객에게 전달되지도 않습니다.

여기서 중요한것은 지금 객체지향 설계를 하며 우리는 소극장, 가방, 매표소와 같은 무생물들도 마치 생물처럼 다룹니다.

레베카 워프스브록(Rebecca Wirfs-Brock)은 능동적이고 자율적인 존재로 소프트웨어 객체를 설계하는 원칙을 가리켜 의인화(anthropomorphism)이라고 부릅니다.

이번 챕터를 공부하며 느낀 점

이번 챕터를 공부하면서 느낀 점은 코딩하는것도 벅찬데 왜 이렇게 설계까지 신경써야 하는가? 하던 생각이 깨졌다는 것이 가장 큰 이익이였다고 생각합니다.

좋은 설계가 있어야 코딩하는 것이 즐겁고, 코딩할때 막막하지 않으며 요구사항 변경을 빠르게 수용하여 내가 만든 프로그램이 세상에서 도태되지 않도록 빠른 변화를 받아들일 수 있기 때문이라고 생각합니다.

은총알은 없다고 합니다.
결국 객체지향 프로그래밍이던 다중 패러다임 프로그래밍이던 상황과 필요에 따라서 채택을 하는 것 뿐,
어떤 것이 옳고 어떤 것이 그른 것이 아니라는 것을 배웠습니다.

아직도 배워가야 할 것이 많지만, 좋은 코드를 위해 끝까지 완독해보겠습니다.

출처 : 오브젝트 코드로 이해하는 객체지향 설계(위키북스, 조영호 저)

DevSeoRex

이전 포스트

JPA - 객체지향 쿼리언어(4)

다음 포스트