[Object] 1장
1. 객체, 설계
티켓 판매 어플리케이션 구현하기
그림 1.1 너무 많은 클래스에 의존하는 Theater
티켓 판매 어플리케이션을 구현한다고 가정했을 때 전체 클래스 설계(그림 1.1)은 잘 돌아갈 것이다. 하지만 이러한 설계에는 문제가 있다.
무엇이 문제인가
로버트 마틴(Robert C. Martin)은 소프트웨어 모듈이 가져야 하는 세 가지 기능에 관해 설명한다.
여기서 모듈이란 크기와 상관 없이 클래스나 패키지, 라이브러리와 같이 프로그램을 구성하는 임의의 요소를 의미한다.
- 모듈은 실행 중에 제대로 동작해야 한다. 이것은 모듈의 존재 이유라고 할 수 있다.
- 모듈은 변경을 위해 존재하는 것이다. 간단한 작업만으로도 변경이 가능해야 한다.
- 모듈은 이해하기 쉬워야한다. 특별한 훈련 없이도 개발자가 쉽게 읽고 이해할 수 있어야 한다.
위의 설계는 제대로 동작해야 한다는 제약은 만족시킨다. 하지만 변경 용이성과 읽는 사람과의 의사소통이라는 목적은 만족시키지 못한다.
예상을 빗나가는 코드
Theater 클래스의 enter 메소드가 수행하는 일을 말로 풀어보자.
소극장은 관람객의 가방을 열어 그 안에 초대장이 들어 있는지 살펴본다. 가방 안에 초대장이 들어 있으면 판매원은 매표소에 보관돼 있는 티켓을 관람객의 가방 안으로 옮긴다. 가방 안에 초대장이 들어 있지 않다면 관람객의 가방에서 티켓 금액만큼의 현금을 꺼내 매표소에 적립한 후에 매표소에 보관돼 있는 티켓을 관람객의 가방 안으로 옮긴다.
문제는 관람객과 판매원이 소극장의 통제를 받는 수동적인 존재라는 점이다. 이해 가능한 코드란 그 동작이 우리의 예상에서 크게 벗어나지 않는 코드이다. 안타깝게도 앞에서 살펴본 예제는 우리의 예상을 벗어난다. 코드를 이해하기 어렵게 만드는 또 다른 이유가 있다. 이 코드를 이해하기 위해서는 여러 가지 세부적인 내용들을 한꺼번에 기억하고 있어야 한다는 점이다.
변경에 취약한 코드
더 큰 문제는 변경에 취약하다는 것이다. 객체 사이의 의존성(dependency) 가 너무 많아 변경이 어렵다. 의존성이라는 말 속에는 어떤 객체가 변경될 때 그 객체에게 의존하는 다른 객체도 함께 변경될 수도 있다는 사실이 내포되어 있다.
그렇다고 객체 사이의 의존성을 완전히 없애는 것이 정답은 아니다. 서로 의존하면서 협력하는 객체들의 공동체를 구축해야한다. 우리의 목표는 애플리케이션의 기능을 구현하는 데 필요한 최소한의 의존성만 유지하고 불필요한 의존성을 제거하는 것이다.
객체 사이의 의존성이 과한 경우를 가리켜 결합도(coupling) 가 높다고 말한다. 두 객체 사이의 결합도가 높으면 높을 수록 함께 변경될 확률도 높아지기 때문에 변경하기 어려워진다. 따라서 설계의 목표는 객체 사이의 결합도를 낮춰 변경이 용이한 설계를 만드는 것이다.
설계 개선하기
위 설계의 문제 중 하나는 의도를 정확하게 의사 소통하지 못하기 때문에 코드가 이해하기 어려워진 것이다. 이해도를 높이기 위해 관람객과 판매원을 자율적인 존재로 만들면 된다.
자율성을 높이자
개념적이나 물리적으로 객체 내부의 세부적인 사항을 감추는 것을 캡슐화(encapsulation) 라고 한다. 캡슐화의 목적은 변경하기 쉬운 객체를 만드는 것이다. 캡슐화를 통해 객체 내부로의 접근을 제한하면 변경 용이성이 증가한다.
그림 1.2 Theater의 결합도를 낮춘 설계
코드를 변경하여 TicketSeller의 자율성을 높여 Theater의 결합도를 낮췄다. Theater는 오직 TicketSeller의 인터페이스(interface) 에만 의존한다. TicketSeller가 내부에 TicektOffice 인스턴스를 포함하고 있다는 사실은 구현(implementation) 의 영역에 속한다. 객체를 인터페이스와 구현으로 나누고 인터페이스만 공개하는 것은 객체 사이의 결합도를 낮추고 변경하기 쉬운 코드로 작성하기 위해 따라야 하는 가장 기본적인 설계 원칙이다.
다음으로 Audience의 캡슐화를 개선하자.
그림 1.3 자율적인 Audience와 TicketSeller로 구성된 설계
코드를 수정한 결과, TicketSeller와 Audience 사이의 결합도가 낮아졌다. 또한 내부 구현이 캡슐화됐으므로 Audience의 구현을 수정하더라도 TicketSeller에는 영향을 미치지 않는다.
어떻게 한 것인가
각 클래스들은 자기 자신의 문제를 스스로 해결하도록 코드를 변경하였다. 우리는 직관을 따랐고 그 결과로 코드는 변경하기 용이하고 이해 가능하도록 수정됐다. 객체의 자율성을 높이는 방향으로 설계를 개선한 결과, 이해하기 쉽고 유연한 설계를 얻을 수 있었다.
캡슐화와 응집도
핵심은 객체 내부의 상태를 캡슐화하고 객체 간에 오직 메시지를 통해서만 상호작용하도록 만드는 것이다.
밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 위임하는 객체를 가리켜 응집도(cohesion) 가 높다고 말한다. 객체의 응집도를 높이기 위해서는 객체 스스로 자신의 데이터를 책임져야한다. 객체는 자신의 데이터를 스스로 처리하는 자율적인 존재여야 한다. 외부의 간섭을 최대한 배제하고 메세지를 통해서만 협력하는 자율적인 객체들의 공동체를 만드는 것이 훌륭한 객체지향 설계를 얻을 수 있는 지름길인 것이다.
절차지향과 객체지향
수정하기 전의 코드에서 Theater의 enter 메소드는 프로세스(Process) 이며 Audience, TicketSeller, Bag, TicketOffice는 데이터(Data) 다. 이처럼 프로세스와 데이터를 별도의 모듈에 위치시키는 방식을 절차적 프로그래밍(Procedural Programming) 이라고 부른다.
절차적 프로그래밍의 세상에서는 데이터의 변경으로 인한 영향을 지역적으로 고립시키기 어렵다는 것이다. 변경은 버그를 부르고 버그에 두려움은 코드를 변경하기 어렵게 만든다. 변경하기 쉬운 설계는 한 번에 하나의 클래스만 변경할 수 있는 설계다. 절차적 프로그래밍은 변경에 취약할 수밖에 없다.
해결 방법은 자신의 데이터를 스스로 처리하도록 해야한다. 데이터와 프로세스가 동일한 모듈 내부에 위치하도록 프로그래밍하는 방식을 객체지향 프로그래밍(Object-Oriented Programming) 이라 부른다. 훌륭한 객체지향 설계의 핵심은 캡슐화를 이용해 의존성을 적절히 관리함으로써 객체 사이의 결합도를 낮추는 것이다.
책임의 이동
절차지향과 객체지향 방식 사이에 근본적인 차이를 만드는 것은 책임의 이동(shift of responsibility) 이다.
그림 1.4 책임이 중앙집중된 절차적 프로그래밍
그림 1.5 책임이 분산된 객체지향 프로그래밍
변경 전의 절차적 설계에서는 Theater가 전체적인 작업을 도맡아 처리했다. 변경 후의 객체지향 설계에서는 각 객체가 자신이 맡은 일을 스스로 처리했다. Theater에 몰려 있던 책임이 개별 객체로 이동하였다. 이것이 바로 책임의 이동이 의미하는 것이다.
객체지향 설계에서는 각 객체에 책임이 적절하게 분배된다. 각 객체는 자신을 스스로 책임진다. 객체지향 애플리케이션은 스스로 책임을 수행하는 자율적인 객체들의 공동체를 구성함으로써 완성된다.
객체지향 설계의 핵심은 적절한 객체에 적절한 책임을 할당하는 것이다. 객체는 다른 객체와의 협력이라는 문맥 안에서 특정한 역할을 수행하는 데 필요한 적절한 책임을 수행해야 한다. 따라서 객체가 어떤 데이터를 가지느냐보다는 객체에 어떤 책임을 할당할 것이냐에 초점을 맞춰야 한다. 적절한 객체에 적절한 책임을 할당하면 이해하기 쉬운 구조와 읽기 쉬운 코드를 얻게 된다.
설계를 어렵게 만드는 것은 의존성이라는 것이다. 해결 방법은 불필요한 의존성을 제거함으로써 객체 사이의 결합도를 낮추는 것이다. 불필요한 세부사항을 캡슐화하는 자율적인 객체들이 낮은 결합도와 높은 응집도를 가지고 협력하도록 최소한의 의존성만을 남기는 것이 훌륭한 객체지향 설계다.
어떤 기능을 설계하는 방법은 한 가지 이상일 수 있다. 동일한 기능을 한 가지 이상의 방법으로 설계할 수 있기 때문에 결국 설계는 트레이드오프의 산물이다.
그래, 거짓말이다!
Theater, Bag, TicketOffice는 실세계에서는 자율적인 존재가 아니다. 하지만 코드 상에서는 무생물 역시 스스로 행동하고 자기 자신을 책임지는 자율적인 존재로 취급하였다. 레베카 워프스브록(Rebecca Wirfs-Brock)은 이처럼 능동적이고 자율적인 존재로 소프트웨어 객체를 설계하는 원칙을 가리켜 의인화(anthopomorphism) 라고 부른다. 훌륭한 객체지향 설계란 소프트웨어를 구성하는 모든 객체들이 자율적으로 행동하는 설계를 가리킨다.
객체지향 설계
설계가 왜 필요한가
설계란 코드를 배치하는 것이다.
설계는 코드를 작성하는 매 순간 코드를 어떻게 배치할 것인지를 결정하는 과정에서 나온다. 좋은 설계란 무엇인가? 우리는 오늘 완성해야 하는 기능을 구현하는 코드를 짜야 하는 동시에 내일 쉽게 변경할 수 있는 코드를 짜야한다. 변경을 수용할 수 있는 설계가 중요한 이유는 요구사항이 항상 변경되기 때문이다. 또 다른 이유는 코드를 변경할 때 버그가 추가될 가능성이 높기 때문이다.
객체지향 설계
따라서 우리가 진정으로 원하는 것은 변경에 유연하게 대응할 수 있는 코드다. 객체지향 프로그래밍은 의존성을 효율적으로 통제할 수 있는 다양한 방법을 제공한다. 변경 가능한 코드란 이해하기 쉬운 코드다.
세상에 존재하는 모든 자율적인 존재처럼 객체 역시 자신의 데이터를 스스로 책임지는 자율적인 존재다. 객체들 사이의 상호작용은 객체 사이에 주고 받는 메시지로 표현된다. 애플리케이션의 기능을 구현하기 위해 객체들이 협력하는 과정 속에서 객체들은 다른 객체에 의존하게 된다.
따라서 훌륭한 객체지향 설계란 협력하는 객체 사이의 의존성을 적절하게 관리하는 설계다.
Leave a comment