예시. 티켓 판매 어플리케이션
시나리오: 소극장에서 이벤트를 통해 초대장을 분배하고 초대장이 있는 사람은 초대장을 티켓으로 교환한 후에 입장하고, 초대장이 없는 사람은 입장권을 구매한 뒤 입장한다.
구현한 클래스 다이어그램은 다음과 같다.
먼저 이벤트 당첨자에게 발송되는 초대장을 구현하는 것으로 시작하자. 초대장(Invitation)은 공연을 관람할 수 있는 초대일자(when)을 인스턴스 변수로 포함하는 간단한 클래스다.
public class Invitation {
private LocalDateTime when;
}공연을 관람하기 원하는 모든 사람은 티켓을 소지하고 있어야만 한다. Ticket 클래스를 추가하자.
public class Ticket {
private Long fee;
public Long getFee() {
return fee;
}
}이벤트 당첨자는 티켓으로 교환할 초대장을 가지고 있다. 당첨되지 않은 사람은 티켓을 구매할 수 있는 현금을 보유하고 있을 것이다. 즉, 관람객이 가지고 올 수 있는 소지품은 초대장, 현금, 티켓 세 가지이다. 소지품의 의미를 담은 Bag 클래스를 추가하자.
Bag 클래스는 초대장의 보유 여부를 판단하는 hasInvitation 메서드와 티켓의 소유 여부를 판단하는 hasTicket 메서드, 현금을 증감하는 plusAmount, minusAmount 메서드, 초대장을 티켓으로 교환하는 setTicket 메서드를 구현하고 있다.
public class Bag {
private Long amount;
private Invitation invitation;
private Ticket ticket;
public Bag(Long amount) {
this(null,amount);
}
public boolean hasInvitation() {
return invitation != null;
}
public boolean hasTicket() {
return ticket != null;
}
public void setTicket(Ticket ticket) {
this.ticket = ticket;
}
public void minusAmount(Long amount) {
this.amount -= amount;
}
public void plusAmount(Long amount) {
this.amount += amount;
}
}관람객이라는 개념을 구현하는 Audience 클래스를 추가하자. 관람객은 소지품을 보관하기 위해 가방을 소지할 수 있다.
public class Audience {
private Bag bag;
public Audience(Bag bag) {
this.bag = bag;
}
public Bag getBag() {
return bag;
}
}매표소에서는 초대장을 티켓으로 교환하거나 티켓을 판매한다. 즉, 매표소에서는 관람객에게 판매할 티켓과 티켓의 판매 금액을 가진다. 판매 금액을 더하는 plusAmount, minusAmount도 구현했다.
public class TicketOffice {
private Long amount;
private List<Ticket> tickets = new ArrayList<>();
public TicketOffice(Long amount, Ticket ... tickets) {
this.amount = amount;
this.tickets.addAll(Arrays.asList(tickets));
}
public Ticket getTicket() {
return tickets.remove(0);
}
public void minusAmount(Long amount) {
this.amount -= amount;
}
public void plusAmount(Long amount) {
this.amount += amount;
}
}판매원은 매표소에서 초대장을 티켓으로 교환해 주거나 티켓을 판매하는 역할을 수행한다. 판매원을 구현한 TicketSeller 클래스는 자신이 일하는 매표소를 알고 있어야 한다.
public class TicketSeller {
private TicketOffice ticketOffice;
public TicketSeller(TicketOffice ticketOffice) {
this.ticketOffice = ticketOffice;
}
public TicketOffice getTicketOffice() {
return ticketOffice;
}
}이제 마지막으로 극장을 구현하는 일만 남았다. 극장을 구현하는 Theater 클래스는 관람객을 맞이할 수 있도록 enter 메서드를 추가한다.
public class Theater {
private TicketSeller ticketSeller;
public Theater(TicketSeller ticketSeller) {
this.ticketSeller = ticketSeller;
}
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);
}
}
}작성한 프로그램의 로직은 간단하고 의도했던 대로 잘 동작한다. 하지만 해당 프로그램은 몇 가지 문제점을 가지고 있다.
무엇이 문제인가
로버트 마틴은 소프트웨어 모듈이 가져야 하는 3가지 기능에 관해 다음과 같이 설명한다.
1) 모듈은 정상적으로 실행되어야 한다
2) 변경에이 용이해야 한다
3) 이해하기 쉬워야 한다.
위 코드는 필요한 기능을 오류없이 정확하게 수행하고 있다. 제대로 동작해야 한다는 제약은 만족시킨다.
하지만, 변경 용이성과 이해하기 쉬워야 한다는 제약은 만족시키지 못하고 있다.
마지막에 구현한 극장(Theater) 클래스를 다시보자. enter() 메서드는 아래의 일을 수행한다.
1. 관람객의 가방을 확인한 후 티켓이 있다면, 티켓을 바로 사용해버린다. 티켓이 없다면 관람객(Audience)의 돈을 직접 매표소에 적립하고 티켓을 가방을 열어 넣어준다.
2. 티켓을 판매할 때 판매원(TicketSeller)의 표를 마음대로 접근한다. 그리고 매표소의 돈을 채울 때도 극장이 판매원을 통제한다.
=> 여기서 발생하는 문제는, 관람객과 판매원이 소극장의 통제를 받는 수동적인 존재라는 점이다.
관람객의 입장에서 소극장이라는 제3자가 초대장을 확인하기 위해 마음대로 가방을 열어본다. 판매원도 마찬가지다. 소극장이 판매원의 허락도 없이 매표소에 보관 중인 티켓과 현금에 마음대로 접근한다. 이러한 일들은 관람객과 판매원의 역할이지 소극장의 역할이 아니다.
이러한 동작들은 우리의 예상을 벗어난다. 우리는 코드를 이해하기 위해 세부적인 내용을 한꺼번에 기억하고 있어야 한다. 그리고 코드를 읽는 사람과 의사소통을 하는 것도 어렵게 된다. 이해 가능한 코드란 그 동작이 우리의 예상을 크게 벗어나지 않는 코드다.
코드를 이해하기 어렵게 만드는 다른 이유도 있다. Theater의 enter() 메서드를 이해하기 위해서는 Audience가 Bag을 가지고 있고, Bag 안에는 현금과 티켓이 들어 있으며, TicketSeller가 TicketOffice에서 티켓을 판매하고, TicketOffice 안에는 돈과 티켓이 보관돼 있다는 모든 사실을 알아야 한다. 이는 코드를 읽고 이해하는 사람에게 큰 부담을 준다.
그리고 무엇보다 큰 문제는 Audience 와 TicketSeller를 변경할 경우 Theater를 함께 변경해야한다는 사실이다.
변경에 취약한 코드
위 코드는 관람객이 현금과 초대장을 보관하기 위해 항상 가방을 들고 다닌다고 가정한다. 또한 판매원이 매표소에서만 티켓을 판매한다고 가정한다.
예를 들어 관람객이 가방을 들고있지 않을 수 있고, 판매원이 매표소 밖에서 티켓을 판매한다고 가정하자. 순간 모든 코드가 일시에 흔들리게 된다.
이것이 객체 사이의 의존성(dependency)과 관련된 문제다.
Theater는 관람객이 가방을 들고 있고 판매원이 매표소에서만 티켓을 판매한다는 지나치게 세부적인 사실에 의존해서 동작한다. 이를 결합도가 높다고 말한다.
결합도가 높을수록 함께 변경될 확률도 높아지기 때문에 변경이 어려워진다.
따라서 설계의 목표는 객체 사이의 결합도를 낮춰 변경이 용이한 설계를 만드는 것이어야 한다.
설계 개선하기
우리는 변경과 의사소통이라는 문제가 서로 엮여 있음에 주목해야 한다.
코드를 이해하기 어려운 이유는 Theater가 관람객의 가방과 판매원의 매표소에 직접적으로 접근하기 때문이다. 이것은 관람객과 판매원이 자신의 일을 스스로 처리해야 한다는 우리의 직관과 벗어난다.
해결 방법은 간단하다. Theater가 Audience와 TicketSeller에 관해 너무 세세한 부분까지 알지 못하도록 정보를 차단하면 된다. Theater는 관람객이 가방을 가지고 있다는 사실과 판매원이 매ㅕ표소에서 티켓을 판매한다는 사실을 알 필요가 없다. Theater는 관람객이 소극장에 입장하는 것만 알면 된다.
즉, 관람객이 스스로 가방 안의 현금과 초대장을 처리하고, 판매원이 스스로 티켓을 판매한다면 모든 문제를 해결할 수 있다. 관람객과 판매원을 자율적인 존재로 만들어야 하는것 이다.
Theater의 enter 메서드에서 TicketOffice에 접근하는 모든 코드를 TicketSeller 내부로 숨겨야 한다. TicketSeller에 sellTo 메서드를 추가하고 Theater에 있던 로직을 옮기자.
public class Theater {
private TicketSeller ticketSeller;
public Theater(TicketSeller ticketSeller) {
this.ticketSeller = ticketSeller;
}
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);
}*/
}
}
public class TicketSeller {
private TicketOffice ticketOffice;
public TicketSeller(TicketOffice ticketOffice) {
this.ticketOffice = ticketOffice;
}
/*public TicketOffice getTicketOffice() {
return ticketOffice;
}*/
public void sellTo(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);
}
}
}TicketSeller에서 getTicketOffice() 메서드가 제거되었다. ticketOffice의 가시성은 private이므로 이제 ticketOffice에 대한 접근은 오직 TicketSeller에서만 가능하다.
TicketSeller는 ticketOffice에서 티켓을 꺼내거나 판매 요금을 적립하는 일을 스스로 수행할 수밖에 없다.
이처럼 개념적이나 물리적으로 객체 내부의 세부적인 사항을 감추는 것을 캡슐화 라고 부른다. 캡슐화를 통해 객체 내부로의 접근을 제한하면 결합도를 낮출 수 있기 때문에 설계를 좀 더 쉽게 변경할 수 있게 된다.
Theater의 enter 메서드는 sellTo 메서드를 호출하는 간단한 코드로 변경된다.
public class Theater {
private TicketSeller ticketSeller;
public Theater(TicketSeller ticketSeller) {
this.ticketSeller = ticketSeller;
}
public void enter(Audience audience){
ticketSeller.sellTo(audience);
}
}수정된 Teater 클래스 어디서도 ticketOffice에 접근할 수 없다.
Theater는 오직 TicketSeller의 인터페이스(interface)에만 의존한다. TicketSeller가 내부에 TickerOffice 인스턴스를 포함하고 있다는 사실을 구현(implementation)의 영역 해당된다.
처음에 봤던 구성도이다. 이 상태에서 Teater의 로직을 TicketSeller로 이동시킨 결과, Theater에서 TicketOffice로의 의존성은 제거된다. TicketOffice와 협력하는 TicketSeller의 내부 구현이 성공적으로 캡슐화 된 것이다.
이제 Audience의 구현을 캡슐화 하자.
Audience의 buy() 메서드를 만들어서 tiketSeller의 sellTo 메서드에서 Bag에 접근하는 부분을 옮기면 된다.
public class TicketSeller {
private TicketOffice ticketOffice;
public TicketSeller(TicketOffice ticketOffice) {
this.ticketOffice = ticketOffice;
}
public void sellTo(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);
}*/
ticketOffice.plusAmount(audience.buy(ticketOffice.getTicket()));
}
}
public class Audience {
private Bag bag;
public Audience(Bag bag) {
this.bag = bag;
}
/*public Bag getBag() {
return bag;
}*/
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가 자신의 가방안에 초대장이 들어있는지 스스로 확인한다. 외부의 제3자가 자신의 가방을 열어보도록 허용하지 않는다. 결과적으로 Bag의 존재를 내부로 캡슐화할 수 있게되었다.
결과적으로 TicketSeller(판매원)는 Audience(관람객)의 인터페이스에만 의존하도록 변경되었다. 이제 TicketeSeller는 Audience의 가방을 가지고 있지 않게 구현을 수정해도 영향을 받지 않게 되었고, Audience와 TicketSeller 사이의 결합도가 낮아졌다.
추가적으로 코드에서는 Audience와 TicketSeller는 자신이 가지고 있는 소지품을 스스로 관리한다. 이것은 우리의 예상과도 정확하게 일치한다. 따라서 코드를 읽는 사람과의 의사소통이라는 관점에서 이 코드는 확실히 개선되었다.
더 중요한 점은 Audience와 TicketSeller는 자신의 문제를 스스로 책임지고 해결하는 자율적인 객체가 되었다. Audience와 TicketSeller의 구현이 변경되었다고 해서 Theater를 함께 변경할 이유가 사라졌다. Audience가 가방이 아니라 지갑을 소지하게 변경하고 싶다면 내부 구현을 변경하면 되고, TicketSeller가 매표소가 아니라 은행에 돈을 보관하고 싶다면 내부 구현만 변경하면 된다.
캡슐화와 응집도
밀접하게 연관된 작업만을 수행하고 연관성이 없는 작업은 다른 객체에게 위임하는 객체를 가리켜 응집도(cohesion)가 높다고 말한다. 자신의 데이터를 스스로 처리하는 자율적인 객체를 만들면 결합도를 낮출 수 있을뿐더러 응집도를 높일 수 있다.
외부의 간섭을 최대한 배제하고 메시지를 통해서만 협력하는 자율적인 객체들의 공동체를 만드는 것이 훌륭한 객체지향 설계를 얻는 길이다.
의인화
객체는 스스로 처리하는 자율적인 존재이기 위해 Audience와 TicketSeller 역시 스스로 자신을 책임져야 한다 했었다. 하지만 Theater는? Bag은? TicketOffice는? 이들은 실세계 에서는 자율적인 존재가 아니다. 가방에서 돈을 꺼내는것은 관람객이지 가방이 아니다.
현실에서는 수동적인 존재라고 하더라도 일단 객체지향의 세계에 들어오면 모든 것이 능동적이고 자율적인 존재로 바뀐다. 무생물 역시 스스로 행동하고 자신을 책임지는 자율적인 존재로 취급하는 것이다.
이처럼 능동적이고 자율적인 존재로 소프트웨어 객체를 설계하는 원칙을 가리켜 의인화(anthropomorphism)이라 부른다.
실세계 에서는 생명이 없는 수동적인 존재라고 하더라고, 객체지향 세계로 넘어오는 순간 그들은 생명과 지능을 가진 존재로 다시 태어난다.
Reference
'Programming > OOP' 카테고리의 다른 글
| 객체지향 생활 체조 원칙 9가지 정리! (0) | 2023.05.22 |
|---|---|
| OOP - IS-A 관계, HAS-A 관계 차이 (상속) (2) | 2022.08.08 |
| OOP - 객체지향이란 무엇인가? (0) | 2022.05.16 |
| 직접 만든 예시로 보는 SOLID 원칙! (0) | 2022.04.25 |