1. Theater 클래스의 enter 메서드 수행하는 일(수동적)
1-1) Theater 현상태
소극장은 관람객의 가방을 열어 그 안에 초대장이 들어 있는지 살펴본다.
가방 안에 초대장이 들어 있으면 판매원은 매표소에 보관돼 있는 티켓을
관람객의 가방 안으로 옮긴다.
가방 안에 초대장이 들어 있지 않다면 관람객의 가방에서 티켓 금액만큼의 현금을
꺼내 매표소에 적립한 후 매표소에 보관돼 있는 티켓을 관람객의 가방 안으로 옮긴다.
1-2) 문제점
문제는 관람객과 판매원이 소극장의 통제를 받는 수동적인 존재라는 점이다.
내가 관람객이라면
소극장이라는 ‘제3자’가 초대장을 확인하기 위해 관람객의 가방을 마음대로
열어 본다는 데 있다. 만약 누군가가 여러분의 허락 없이 가방 안의 내용물을
마음대로 뒤적이고 그 돈을 가져간다면 어떻겠는가?
넋 놓고 다른 사람이 여러분의 가방을 헤어집어 놓는 것을 멍하니 바라만 볼 것인가?
내가 판매원이라면
소극장이 여러분의 허락도 없이 매표소에 보관 중인 티켓과 현금을 마음대로 접근할 수 있기 때문
더 큰 문제는 티켓을 꺼내 관람객의 가방에 집어넣고 관람객에게 받은 돈을 매표소에
적립하는 일은 여러분이 아닌 소극장이 수행한다는 점이다.
여러분은 매표소 안에 가만히 앉아 티켓이 하나씩 사라지고 돈이 저절로 쌓이는 광경을
두 손 놓고 쳐다볼 수밖에 없는 것이다.
1-3) 이해 가능한 코드
그 동작이 우리의 예상에 크게 벗어나지 않는 코드다.
코드를 이해하기 어렵게 만드는 이유는 이 코드를 이해하기 위해서는 세부적인 내용을
한 번에 기억하고 있어야 한다는 점이다.
Theater
enter 메서드를 이해하기 위해서는 Audience가 Bag을 가지고 있고,
Bag 안에는 현금과 티켓이 들어 있으며, TicketSeller가 TicketOffice에서 티켓을 판매하고
TicketOffice안에 돈과 티켓이 보관돼 있다는 모든 사실을 동시에 기억하고 있어야 함.
이 코드는 하나의 클래스나 메서드에서 너무 많은 세부사항을 다루기 때문에
코드를 작성하는 사람뿐만 아니라 코드를 읽고 이해해야 하는 사람 모두에게 큰 부담을 준다.
Audience와 TicketSeller를 변경할 경우 Theater도 함께 변경해야한다는 문제점이 있음.
2. 결합도가 높은 Theater 클래스
2-1) 너무 많은 클래스에 의존하는 Theater
2-2) 결합도
객체 사이의 의존성이 과한 경우를 결합도가 높다고 말한다. 반대로 객체들이 합리적인 수준으로
의존할 경우에는 결합도가 낮다고 말한다.
결합도는 의존성과 관련돼 있기 때문에 결합도 역시 변경과 관련이 있다.
두 객체 사이의 결합도가 높으면 높을수록 함께 변경될 확률도 높아지기 때문에 변경하기 어려워짐.
설계의 목표는 객체 사이의 결합도를 낮춰 변경이 용이한 설계를 만드는 것이어야 한다.
3. 자율성을 높이기
3-1) 설계를 변경하기 어려운 이유
Theater가 Audience와 TicketSeller뿐만 아니라 Audience 소유의 Bag과
TicketSeller가 근무하는 TicketOffice까지 마음대로 접근할 수 있기 때문이다.
3-2) 해결방법
Audience와 TicketSeller가 직접 Bag과 TicketOffice에 접근하는 모든 코드를 TicketSeller 내부
로 숨기는 것. TicketSeller에 sellTo 메서드를 추가하고 Theater에 있던 로직을 이 메서드로 옮기기
3-3) Theater의 결합도 낮추기
3-3)-1. Theater
변경하기 쉬운 객체를 만드는 거임. 캡슐화를 통해 객체 내부로의 접근을 제한하면
객체와 객체 사이의 결합도를 낮출 수 있기 때문에 설계를 좀 더 쉽게 변경할 수 있게 됨.
3-3)-2. TicketSeller
4. Theater의 결합도를 낮춘 설계
