오브젝트 Chapter 01

메모

Chapter 01. 객체, 설계

"모든 모듈은 제대로 실행돼야 하고, 변경이 용이해야 하며, 이해하기 쉬워야 한다."

1. 여러분이 관람객이라고 가정해보자. 관람객의 입장에서 문제는 소극장이라는 제3자가 초대장을 확인하기 위해 관람객의 가방을 마음대로 열어 본다는 데 있다. 만약 누군가가 여러분의 허락 없이 가방 안의 내용물을 마음대로 뒤적이고 돈을 가져간다면 어떻겠는가? 넋놓고 다른 사람이 여러분의 가방을 헤집어 놓는 것을 멍하니 바라만 볼 것인가? (p. 15)

   Theater 클래스에서 audience.getBag().hasInvitation() 을 통해 Audience 의 Bag 을 확인하는 것을 위와 같은 상황에 비유하였다.

2. 여기서 변경과 의사소통이라는 문제가 서로 엮여 있다는 점에 주목하라. 코드를 이해하기 어려운 이유는 Theater 가 관람객의 가방과 판매원의 매표소에 직접 접근하기 때문이다. 이것은 관람객과 판매원이 자신의 일을 스스로 처리해야 한다는 우리의 직관을 벗어난다. 다시 말해서 의도를 정확하게 의사소통하지 못하기 때문에 코드가 이해하기 어려워진 것이다. 해결 방법은 간단하다. Theater 가 Audience 와 TicketSeller 에 관해 너무 세세한 부분까지 알지 못하도록 정보를 차단하면 된다. 다시 말해서 관람객과 판매원을 자율적인 존재로 만들면 되는 것이다. (p. 15-16)

   Theater 클래스 안의 enter(Audience audience) 를 보면, ticketSeller 와 audience 의 속성에 직접 접근하고 있다.

3. 프로세스와 데이터를 별도의 모듈에 위치시키는 방식을 절차적 프로그래밍(Procedural Programming)이라고 부른다. Theater 가 TicketSeller, TicketOffice, Audience, Bag 모두에 의존하고 있음에 주목하라. 이것은 모든 처리가 하나의 클래스 안에 위치하고 나머지 클래스는 단지 데이터(Data)의 역할만 수행하기 때문이다. (p. 26)
   데이터와 프로세스가 동일한 모듈 내부에 위치하도록 프로그래밍하는 방식을 객체지향 프로그래밍(Object-Oriented-Programming)이라고 부른다. (p. 27)

4. 객체지향 설계에서는 독재자가 존재하지 않고 각 객체에 책임이 적절하게 분배된다. 따라서 각 객체는 자신을 스스로 책임진다. 객체지향 애플리케이션은 스스로 책임을 수행하는 자율적인 객체들의 공동체를 구성함으로써 완성된다. (p. 28)

5. 설계를 어렵게 만드는 것은 의존성이라는 것을 기억해라. 해결 방법은 불필요한 의존성을 제거함으로써 객체 사이의 결합도를 낮추는 것이다. 예제에서 결합도를 낮추기 위해 선택한 방법은 Theater 가 몰라도 되는 세부사항을 Audience 와 TicketSeller 내부로 감춰 캡슐화하는 것이다. 결과적으로 불필요한 세부사항을 객체 내부로 캡슐화하는 것은 객체의 자율성을 높이고 응집도 높은 객체들의 공동체를 창조할 수 있게 한다. (p. 29)

6. Theater 는 어떤가? Bag 은? TicketOffice 는? 이들은 실세계에서는 자율적인 존재가 아니다. 그럼에도 불구하고 우리는 이들을 관람객이나 판매원과 같은 생물처럼 다뤘다. 무생물 역시 스스로 행동하고 자기 자신을 책임지는 자율적인 존재로 취급한 것이다.
   비록 현실에서는 수동적인 존재라고 하더라도 일단 객체지향의 세계에 들어오면 모든 것이 능동적이고 자율적인 존재로 바뀐다. (p. 33)

정리

소프트웨어 모듈의 세 가지 목적

1. 실행 중에 제대로 동작하는 것.
2. 변경을 위해 존재하는 것.
3. 코드를 읽는 사람과 의사소통하는 것.

실행 중에 제대로 동작하는 것은 모듈의 존재 이유이므로 항상 바탕이 되어야 하며, 변경하기 어려운 모듈 또는 읽는 사람과 의사소통할 수 없는 모듈은 개선해야 한다.

예상에서 크게 벗어나지 않는 코드

1. 우리의 상식과 다르게 동작하는 코드는 읽는 사람과 제대로 의사소통하지 못하게 만든다.
2. 하나의 클래스 또는 하나의 메서드에서 너무 많은 세부사항을 다루면 코드를 작성하는 사람뿐만 아니라 코드를 읽고 이해해야 하는 사람 모두에게 부담이 된다.

코드 변경과 의존성

객체 사이의 의존성은 코드의 변경과 관련돼 있다. 의존성은 변경에 대한 영향을 암시한다. 의존성이라는 말 속에는 어떤 객체가 변경될 때 그 객체에 의존하는 다른 객체도 함께 변경될 수 있다는 사실이 내포돼 있다. 객체 사이의 의존성이 과한 경우를 가리켜 결합도가 높다고 말한다.

협력하는 관계

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

객체의 자율성

객체를 자율적인 존재로 만들면 결합도도 낮아지고 의도를 보다 명확하게 나타낼 수 있다. 자율적인 객체는 자신의 일을 스스로 처리하기 때문에 다른 객체가 자신의 세세한 부분까지 알아야 할 필요가 없어진다. 따라서 자연스럽게 응집도가 높아지며 객체는 캡슐화된다.

설계는 균형

설계는 균형이다. 훌륭한 설계는 적절한 트레이드오프의 결과물이다. 어떤 것을 우선해야 하는지 판단하여 균형을 잘 맞추는 것이 중요하다.