[책 읽기][오브젝트] 01. 객체, 설계

 

싸니까 믿으니까 인터파크도서

 

책 소개

 

현재 업무로 담당하고 있는 프로젝트에서 가장 많이 쓰이는 언어인 자바. 그것은 바로 객체 지향 언어이다.

자바를 사용하는 것은 익숙하다 할지라도 실제로 깊게 공부해 보지 않았기에 객체 지향 프로그래밍을 더욱 알고 싶었다!

 

실제로 글쓴이께서 언급하신 이 책의 대상 독자 역시 아래와 같다. (나는 과연 능숙할까? 😅)

• 언어를 능숙하게 다룰 수 있으며,
• 실무 프로젝트에서 충분한 프로그래밍 경험을 쌓은 분

다소 두껍긴 하지만 코드를 통해 설명하시는 점이 너무너무 like like!

타 도서 대비 문장이 자연스럽고 읽기에도 편했던거 같다. 

꼭 1독 하고 싶어서 블로그를 쓰게 되는데 .... (끝낼 수 있을지 모르겠다 ㅎㅎㅎㅎ)

 

 

 

---

 

 

01. 객체, 설계

 

 

이론이 먼저일까, 실무가 먼저일까?
- 로버트 L. 글래스

 

 

컴퓨터라는 도구가 세상에 출한 이후 정말 많은 소프트웨어가 설계되고 개발돼 왔다. 초기부터 소프트웨어의 발전을 이끈 실무에 비해 대부분의 설계 원칙과 개념은 실무에서 반복적으로 적용되던 기법들이 이론화된 것들이 대부분이다. 설계 뿐만 아니라 소프트웨어 유지보스의 경우에도 마찬가지! 이러한 주장을 바탕으로 이 책은 이론과 개념은 잠시 뒤로 미루고 간단한 프로그램으로 책을 시작한다 두둥-

 

 

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

 

전체적인 플로우는 간단하다.

• Theater에는 TicketSeller가 있다.
• TicketSeller는 TicketOffice를 통해 티켓을 판매한다.
• Audience는 Bag안에 Invitation을 가질 수 있다.
• TicketOffice는 Audience에게 Invitation이 있는지 확인하고, 있으면 Ticket를 주고 아니면 Fee를 받고 판매한다

 

 

 

문제점

 

모든 소프트웨어 모듈에는 세 가지 목적이 있다.
첫 번째 목적은 실행 중에 제대로 동작하는 것이다. 이것은 모듈의 존재 이유라고 할 수 있다.
두 번째 목적은 변경을 위해 존재하는 것이다. 대부분의 모듈은 생명주기 동안 변경되기 때문에 간단한 작업만으로도 변경이 가능해야 한다. 변경하기 어려운 모듈은 제대로 동작하더라도 개선해야 한다.
모듈의 세 번째 목적은 코드를 읽는 사람과 의사소통 하는 것이다. 모듈은 특별한 훈련 없이도 개발자가 쉽게 읽고 이해할 수 있어야 한다. 읽는 사람과 의사소통할 수 없는 모듈은 개선해야 한다.
- 로버트 마틴 (Robert C. Martin)

 

위에서 사용된 Theater의 enter 함수는 아래와 같다.

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

책에서 사용된 전체 코드는 생략하였지만 위 코드만 보았을 때에도 보이는 문제점이 있었다.

1. 예상을 빗나가는 코드: 관람객과 판매원이 소극장의 통제를 받는 수동적인 존재라는 점. enter을 이해하기 위해서는 기억해야 하는 사실이 많은 점(Audience가 Bag을 가지고 있고, Bag에는 현금과 티켓이 있고, TicketSeller가 TickerOffice에서 티켓을 판매 등).
2. 변경에 취약한 코드: 관람객이 가방을 들고 있지 않다면? 현금이 아니라 신용카드를 사용한다면? 매표소 밖에서 티켓을 판매한다면?

 

이를 개선하기 위해 가장 우선적으로 관람객과 판매원을 자율적인 존재로 만들어 주었다. 위 코드는 Theater가 관람객의 Bag, TicketSeller의 ticketOffice까지 마음대로 접근하고 있다. 이들을 분리해 주자! 

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

// TicketSeller.java
public void sellTo(Audience audience) {
	if (audience.getBag().hasInvitation()) {
    	Ticket ticket = ticketOffice.getTicket();
        audience.getBag().setTicket(ticket);
    } else {
    	Ticket ticket = ticketOffice.getTicket();
        audience.getBag().minusAmount(ticket.getFee());
        ticketOffice.plusAmount(ticket.getFee());
        audience.getBag().setTicket(ticket);
    }
}

 

위 처럼 TicketSeller에 sellTo()라는 함수를 만들어 주었으며 이와 더불어 TicketSeller에 있던 getTicketOffice()는 삭제할 수 있게 되었다. ticketOffice에 대한 접근은 오직 TicketSeller 안에서만 존재하게 되는 것이다. 이처럼 개념적이나 물리적으로 객체 내부의 세부적인 사항을 감추는 것을 캡슐화(encapsulation) 라고 부른다. 이를 통해 객체와 객체 사이의 결합도(coupling)을 낮출 수 있기 때문에 설계를 좀 더 쉽게 변경할 수 있게 된다.

 

추가적으로, sellTo()를 보면 TicketSeller가 관람객의 Bag에 접근하는 것을 볼 수 있을텐데 여전히 Audience는 자율적이지 못한 존재인 것을 알 수 있다. 위 방법과 똑같이 Audience를 자유롭게 해 주자!

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

// Audience.java
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는 자신의 가방 안에 초대장이 들어있는지를 스스로 확인한다. getBag()도 제거할 수 있고 결과적으로 Bag의 존재를 내부로 캡슐화할 수 있게 됐다! (yeah!)

 

 

 

 

어떻게 (How?)

 

지금까지 수행한 수정 사항은 아래와 같다.

• TicketOffice를 사용하는 모든 부분을 TicketSeller 내부로 옮기기
• 관람객이 티켓을 구매하기 위해  Bag을 사용하는 모든 부분을 Audience 내부로 옮기기

 

캡슐화와 응집도

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

• Theater는 TicketSeller의 내부에 대해 알지 못한다. → sellTo()를 통해서만 상호작용
• TicketSeller는 Audience의 내부에 대해 알지 못한다. → buy()를 통해서만 상호작용

이와 같이 밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 위임하는 객체를 가리켜 응집도(cohension)가 높다고 말한다. 객체의 응집도를 높이기 위해서는 객체 스스로 자신의 데이터를 책임져야 한다.

 

 

절차지향과 객체지향

 

수정하기 전의 코드는 절차지향적 프로그래밍(Procedural Programming: 프로세스와 데이터를 별도의 모듈에 위치시키는 방식) 이라고 할 수 있다. Audience, TicketSeller, Bag, TicketOffice는 필요한 정보들을 제공하고 모든 처리는 Theater의 enter() 메소드 내에서 이루어 졌기 때문이다. 이러한 절차지향적 프로그래밍은 아래의 취약한 점을 가진다.

• 직관에 위배 (관람객과 판매원이 수동적인 존재)
• 데이터의 변경으로 인한 영향을 지역적으로 고립시키기 어려움

이를 해결하기 위해 프로세스의 적절한 단계를 Audience와 TicketSeller로 이동시키었다. 수정한 후에는 데이터를 사용하는 프로세스가 데이터를 소유하게 되었는데 이를 객체지향 프로그래밍(Object-Oriented Programming: 데이터와 프로세스가 동일한 모듈 내부에 위치한 방식) 이라고 부르며 변경된 결과는 아래와 같다.

• 의존성이 적절히 통제 (Theater는 오직 TicketSeller에만 의존)
• 하나의 변경으로 인한 여파가 여러 클래스로 전파되는 것을 효율적으로 억제

 

책임의 이동

 

수정 전에는 대부분의 책임, 즉 작업 흐름이 주로 Theater에 의해 제어되었다. 책임이 Theater에 집중되어 있는 것이다. 하지만 이를 변경 시켜 하나의 기능을 완성하는 데 필요한 책임이 여러 객체에 걸쳐 분산되도록 하였다. 다시 말해 Theater에 몰려 있던 책임이 개별 객체로 이동한 것이며 이는 책임의 이동을 의미한다.

 

 

객체 지향 설계에서는 독재자가 존재하지 않으며 각 객체는 자신을 스스로 책임진다. 다른 말로 데이터와 프로세스를 하나의 단위로 통합해 놓는 방식이라고 할 수 있다. 글쓴이는 이 책을 일고 나면 객체지향 안에는 단순히 데이터와 프로세스를 하나의 객체 안으로 모으는 것 이상의 무엇이 있다는 점을 알게 될 것이라 말한다. (또잉?) 객체지향 설계의 핵심은 바로 적절한 객체에 적절한 책임을 할당하는 것!

 

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

 

 

더 나아가기

 

코드를 더 자세히 살펴 보면 Bag과 TicketOffice의 자율권 역시 침해되고 있다는 점을 알 수 있을 것이다. 위에서 배운 내용을 바탕으로 이 부분도 변경해 보는 것은 어떨까? (클린코드를 위해 코드를 변경할 수도 있을 것!)

 

코드를 변경하다 보면 무언가 트레이드 오프해야 할 부분도 생길 것이며 선택의 기로에 서게 될 순간이 올 것이다. 어떤 경우에도 모든 사람들을 만족시킬 수 있는 설계는 만들 수 없다! (ㅜㅜ) 균형의 예술, 설계! 무엇이 더 나을까 고민하는 시간이 개발자들에게는 무엇보다 값진 시간이 되지 않을까?

 

 

 

- mushroong

 

 

 

 

---