오브젝트 1-2. 무엇이 문제인가

무엇이 문제인가

로버트 마틴은 '클린 소프트웨어: 애자일 원칙과 패턴, 그리고 실천 방법'에서 소프트웨어 모듈이 가져야 하는 세 가지 기능에 관해 설명한다.

• 모듈 : 크기와 상관 없이 클래스나 패키지, 라이브러리와 같이 프로그램을 구성하는 임의의 요소

모든 소프트웨어 모듈에는 세 가지 목적이 있다.

1. 실행 중에 제대로 동작하는 것이다. 이것은 모듈의 존재 이유라고 할 수 있다.

2. 변경을 위해 존재하는 것이다. 대부분의 모듈은 생명주기 동안 변경되기 때문에 간단한 작업만으로도 변경이 가능해야 한다.

3. 코드를 읽는 사람과 의사소통하는 것이다. 모듈은 특별한 훈련 없이도 개발자가 쉽게 읽고 이해할 수 있어야 한다. 읽는 사람과 의사소통할 수 없는 모듈은 개선해야 한다.

앞 글의 애플리케이션에서는 제대로 동작해야 한다는 제약은 만족시킨다. 하지만 변경 용이성과 읽는 사람과의 의사소통이라는 목적은 만족시키지 못한다.

 

예상을 빗나가는 코드

Theater 클래스의 enter 메서드가 수행하는 일을 말로 풀어보자.

소극장은 관람객의 가방을 열어 그 안에 초대장이 들어 있는지 살펴본다.

가방 안에 초대장이 들어 있으면 판매원은 매표소에 보관돼 있는 티켓을 관람객의 가방 안으로 옮긴다.

가방 안에 초대장이 들어 있지 않다면 관람객의 가방에서 티켓 금액만큼의 현금을 꺼내 매표소에 적립한 후에 매표소에 보관돼 있는 티켓을 관람객의 가방 안으로 옮긴다.

문제는 관람객과 판매원이 소극장의 통제를 받는 수동적인 존재라는 점이다.

 

관람객의 입장에서의 문제

소극장이라는 제3자가 초대장을 확인하기 위해 관람객의 가방을 마음대로 열어 본다는 데 있다.

만약 누군가가 여러분의 허락 없이 가방 안의 내용물을 마음대로 뒤적이고 돈을 가져간다면 어떻겠는가?

 

판매원의 입장에서의 문제

소극장이 여러분의 허락도 없이 매표소에 보관 중인 티켓과 현금에 마음대로 접근할 수 있기 때문이다.

더 큰 문제는 티켓을 꺼내 관람객의 가방에 집어넣고 관람객에게서 받은 돈을 매표소에 적립하는 일은 여러분이 아닌 소극장이 수행한다는 점이다.

 

코드를 이해하기 어렵게 만드는 이유

현실에서는 관람객이 직접 자신의 가방에서 초대장을 꺼내 판매원에게 건넨다. 티켓을 구매하는 관람객은 가방 안에서 돈을 직접 꺼내 판매원에게 지불한다.

판매원은 매표소에 있는 티켓을 직접 꺼내 관람객에게 건네고 관람객에게서 직접 돈을 받아 매표소에 보관한다.

하지만 코드 안의 관람객, 판매원은 그렇게 하지 않는다. 현재의 코드는 우리의 상식과는 너무나도 다르게 동작하기 때문에 코드를 읽는 사람과 제대로 의사소통하지 못한다.

 

코드를 이해가 어렵게 만드는 또 다른 이유는 코드를 이해하기 위해 여러 가지 세부적인 내용들을 한꺼번에 기억하고 있어야 한다는 점이다.

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

하지만 가장 심각한 문제는 Audience와 TicketSeller를 변경할 경우 Theater도 함께 변경해야 한다는 사실이다.

 

변경에 취약한 코드

더 큰 문제는 변경에 취약하다는 것이다.

관람객이 가방을 들고 있다는 가정이 바뀌었다고 상상해보자.

• Audience 클래스에서 Bag을 제거
• Audience의 Bag에 직접 접근하는 Theater의 enter 메서드 수정

Theater는 관람객이 가방을 들고 있고 판매원이 매표소에서만 티켓을 판매한다는 지나치게 세부적인 사실에 의존해서 동작한다.

이처럼 다른 클래스가 Audience의 내부에 대해 더 많이 알수록 Audience를 변경하기 어려워진다.

 

의존성 (Dependency)

의존성은 변경에 대한 영향을 암시한다. 의존성이라는 말 속에는 어떤 객체가변경될 때 그 객체에서 의존하는 다른 객체도 함께 변경될 수 있다는 사실이 내포돼 있다.

그렇다고 해서 객체 사이의 의존성을 완전히 없애는 것이 정답은 아니다.

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

 

결합도 (Coupling)

객체 사이의 의존성이 과한 경우를 가리켜 결합도가 높다고 말한다. 반대로 객체들이 합리적인 수준으로 의존할 경우에는 결합도가 낮다고 말한다.

두 객체 사이의 결합도가 높으면 높을수록 함께 변경될 확률도 높아지기 때문에 변경하기 어려워진다.

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