01. 객체, 설계
소프트웨어 개발에서 실무가 이론보다 앞서 있는 대표적인 분야로 '소프트웨어 설계'와 '소프트웨어 유지보수'를 들 수 있다. 컴퓨터라는 도구가 세상에 출현한 이후 지금까지 셀 수 없을 정도로 많은 수의 소프트웨어가 설계되고 개발돼 왔다. 따라서 실무는 훌륭한 소프트웨어 설계를 위해 필요한 다양한 기법과 도구를 초기부터 성공적으로 적용하고 발전시켜 왔던 것이다.
01. 티켓 판매 애플리케이션 구현하기
추첨을 통해 선정된 관람객에게 공연을 무료로 관람할 수 있는 초대장을 발송하는 것이다.
이벤트 당첨자에게 발송되는 초대장을 구현하는 것으로 시작하자. 초대장이라는 개념을 구현한 Invitation 은 공연을 관람할 수 있는 초대 일자(when)을 인스턴스 변수로 포함하는 간단한 클래스다.
public class Invitation {
private LocalDateTime when;
}공연을 관람하기 원하는 모든 사람들은 티켓을 소지하고 있어야만 한다. Ticket 클래스를 추가하자.
public class Ticket {
private Long fee;
public Long getFee() {
return fee;
}
}이벤트 당첨자는 티켓을 교환할 초대장을 가지고 있을 것이다.
이벤트에 당첨되지 않은 관람객은 티켓을 구매할 수 있는 현금을 보유하고 있을 것이다.
관람객이 소지품을 보관할 Bag 클래스를 추가하자.
public class Bag {
private Long amount;
private Invitation invitation;
private Ticket ticket;
public boolean hasInvitation() {
return invitation != null;
}
public boolean hasTicket() {
return ticket != null;
}
public void minusAmount(Long amount) {
this.amount -= amount;
}
public void plusAmount(Long amount) {
this.amount += amount;
}
}이벤트에 당첨잔 관람객 가방 안에는 현금과 초대장이 들어있지만 이벤트에 당첨되지 않은 관람객의 가방 안에는 초대장이 들어있지 않을 것이다. 따라서 Bag 인스턴스의 상태는 현금과 초대장을 함께 보관하거나, 초대장 없이 현금만 보관하는 두 가지 중 하나 일 것이다.
이 제약을 강제할 수 있도록 생성자를 추가하자.
public class Bag {
public Bag(long amount) {
this(null, amount);
}
public Bag(Invitation invitation, long amount) {
this.invitation = invitation;
this.amount = amount;
}
}다음은 관람객 Audience 클래스를 만들 차례다. 관람객은 가방을 소지할 수 있다.
public class Audience {
private Bag bag;
private Audience(Bag bag) {
this.bag = bag;
}
public Bag getBag() {
return bag;
}
}관람객이 소극장에 입장하기 위해서는 매표소에 초대장을 티켓으로 교환하거나 구매해야 한다. 따라서 매표소에는 관람객들에게 판매할 티켓과 티켓의 판매 금액이 보관돼 있어야 한다. 매표소를 구현하기 위해 TicketOffice 클래스를 추가할 시간이다.
판매하거나 교환해 줄 티켓의 목록(tickets)과 판매 금액(amount)을 인스턴스 변수로 포함한다.
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;
}
}판매원은 매표소에서 초대장을 티켓으로 교환해 주거나 티켓을 판매하는 역할을 수행한다.
public class TicketSeller {
private TicketOffice ticketOffice;
public TicketSeller(TicketOffice ticketOffice) {
this.ticketOffice = ticketOffice;
}
public TicketOffice getTicketOffice() {
return ticketOffice;
}
}
소극장을 구현하는 클래스는 Theater다. 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);
}
}
}이 작은 프로그램은 몇 가지 문제점을 가지고 있다.
02. 무엇이 문제인가.
로버트 마틴은 소프트웨어 모듈이 가져야 하는 세 가지 기능에 관해 설명한다. 여기서 모듈이란 크기와 상관없이 클래스나 패키지, 라이브러리와 같은 프로그램을 구성하는 임의의 요소를 말한다.
소프트웨어 모듈에는 세 가지 목적이 있다.
1. 실행 중에 제대로 동작하는 것
2. 목적은 변경을 위해 존재하는 것
3. 코드를 읽는 사람과 의사소통하는 것
예상을 빗나가는 코드
Theater 클래스의 enter 메서드가 수행하는 일을 말로 풀어보자.
소극장은 관람객의 가방을 열어 그 안에 초대장이 들어 있는지 살펴본다. 가방 안에 초대장이 들어 있으면 판매원은 매표소에 보관돼 있는 티켓을 관람객의 가방 안으로 옮긴다. 가방 안에 초대장이 들어 있지 않으면 관람객의 가방에서 티켓 금액만큼의 현금을 꺼내 매표소에 적립한 후에 매표소에 보관돼 있는 티켓을 관람객의 가방 안으로 옮긴다.
문제는 관람객과 판매원이 소극장의 통제를 받는 수동적인 존재라는 점이다.
이 코드는 하나의 클래스나 메서드에서 너무 많은 세부사항을 다루기 때문에 코드를 작성하는 사람뿐만 아니라 읽고 이해하는 사람 모두에게 부담을 준다.
가장 큰 문제점은 Audience와 TicketSeller를 변경할 경우 Theather도 함께 변경해야 한다는 사실이다.
변경에 취약한 코드
이 코드는 관람객이 항상 가방을 들고 다닌다고 가정한다. 판매원이 매표소에서만 티켓을 판매한다고 가정한다. 이런 가정이 깨는 순간 모든 코드가 흔들리게 된다.
이것은 객체 사이의 의존성(dependency)과 관련된 문제다. 문제는 의존성이 변경과 관련돼 있다는 점이다. 의존성은 변경에 대한 영향을 암시한다. 의존성이라는 말 속에는 어떤 객체가 변경될 때 그 객체에게 의존하는 다른 객체도 함께 변경될 수 있다는 사실이 내포되어 있다.
객체 사이의 의존성이 과한 경우를 가리켜 결합도(coupling)가 높다고 말한다. 반대로 객체들이 합리적인 수준으로 의존할 경우에는 결합도가 낮다고 말한다. 결합도는 의존성과 관련돼 있기 때문에 결합도 역시 변경과 관련이 있다 두 객체 사이의 결합도가 높으면 높을수록 함께 변경될 확률도 높아지기 때문에 변경하기 어려워진다. 따라서 설계의 목표는 객체 사이의 결합도를 낮춰 변경이 용이한 설계를 만드는 것이다.
03. 설계 개선하기
예제 코드는 로버트 마틴이 이야기한 세 가지 목적 중 한 가지는 만족시키지만(실행 중에 제대로 동작하는 것) 다른 두 조건으로 만족시키지 못한다. 이 코드는 기능은 제대로 수행하지만 이해하기 어렵고 변경하기가 쉽지 않다.
해결 방법은 간단하다. Theater가 Audience와 TicketSeller에 관해 너무 세세한 부분까지 알지 못하도록 정보를 차단하면 된다. 사실 관람객이 가방을 가지고 있다는 사실과 판매원이 매표소에서 티켓을 판매한다는 사실을 Theater가 알야아 할 필요가 없다. Theater가 원하는 것은 관람객이 소극장에 입장하는 것뿐이다. 따라서 관람객이 스스로 가방 안의 현금과 초대장을 처리하고 판매원이 스스로 매표소의 티켓과 판매 요금을 다루게 한다면 이 모든 문제를 한 번에 해결할 수 있을 것이다.
다시 말해서 관람객과 판매원을 자율적인 존재로 만들면 되는 것이다.
자율성을 높이자
첫 번째 단계는 Theater의 enter 메서드에서 Ticketoffice에 접근하는 모든 코드를 TicketSeller 내부로 숨기는 것이다.
public class TicketSeller {
private TicketOffice ticketOffice;
public TicketSeller(TicketOffice ticketOffice) {
this.ticketOffice = ticketOffice;
}
public void sellTo(Audience audience) {
if (audience.getBag().hasInvitation()) {
Ticket ticket = ticketOffice.getTicket();
audience.getBag().setTicket(ticket);
} else {
Ticket ticket = ticketOffice.getTicket();
audience.getBag().minusAmount(ticket.getFee());
ticketOffice.plusAmount(ticket.getFee());
audience.getBag().setTicket(ticket);
}
}
}TicketSeller에서 getTicketOffice 메서드가 제거됐다.
ticketOffice 인스턴스 변수는 접근 제어자가 private이고 접근 가능한 public 메서드가 더 이상 존재하지 않기 때문에 외부에서는 ticketOffice에 접근할 수 없다.
이처럼 개념ㅈ먹이나 물리적으로 객체 내부의 세부적인 사항을 감추는 것을 캡슐화(encapsulation)라고 부란다. 캡슐화의 목적은 변경하기 쉬운 객체를 만드는 것이다. 캡슐화를 통해 객체 내부로의 접근을 제한하면 객체와 객체 사이의 결합도를 낮출 수 있기 때문에 설계를 좀 더 쉽게 변경할 수 있게 된다.
public class Theater {
private TicketSeller ticketSeller;
public Theater(TicketSeller ticketSeller) {
this.ticketSeller = ticketSeller;
}
public void enter(Audience audience) {
ticketSeller.sellTo(audience);
}
}Theater는 오직 TicketSeller의 인터페이스(interface)에만 의존한다. TicketSeller가 내부에 TicketOffice 인스턴스를 포함하고 있다는 사실은 구현(implementation)의 영역에 속한다. 객체를 인터페이스와 구현으로 나누고 인터페이스만을 공개하는 것은 객체 사이의 결합도를 낮추고 변경하기 쉬운 코드를 작성하기 위해 따라야 하는 가장 기본적인 설계 원칙이다.
TicketSeller 다음으로 Audience의 캡슐화를 개선하자.
public class Audience {
private Bag bag;
private 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 스스로 가방 안에 초대장이 들어있는지 확인한다.
이제 TicketSeller가 Audience의 인터페이스에만 의존하도록 수정하자. TicketSeller가 buy 메서드를 호출하도록 코드를 변경하면 된다.
public class TicketSeller {
private TicketOffice ticketOffice;
public TicketSeller(TicketOffice ticketOffice) {
this.ticketOffice = ticketOffice;
}
public void sellTo(Audience audience) {
ticketOffice.plusAmount(audience.buy(ticketOffice.getTicket()));
}
}TicketSeller와 Audience 사이의 결합도가 낮아졌다.
무엇이 개선됐는가
로버틴 마틴의 변경 용이성과 의사소통이 개선되었다.
Audience와 TicketSeller의 내부 구현을 변경하더라도 Theater를 함께 변경할 필요가 없다.
어떻게 한 것인가
판매자가 티켓을 판매하기 위해 TicketOffice를 사용하는 모든 부분을 TicketSeller 내부로 옮기고, 관람객이 티켓을 구매하기 위해 Bag을 사용하는 모든 부분을 Audience 내부로 옮긴 것이다. 다시 말해 자기 자신의 문제를 스스로 해결하도록 코드를 변경한 것이다.
캡슐화와 응집도
핵심은 객체 내부의 상태를 캡슐화하고 객체 간에 오직 메시지를 통해서만 상호작용하도록 만드는 것이다.
밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 위임하는 객체를 가리켜 응집도(cohension)가 높다고 말한다. 자신의 데이터를 스스로 처리하는 자율적인 객체를 만들면 결합도를 낮출 수 있을뿐더러 응집도를 높일 수 있다.
객체의 응집도를 높이기 위해서는 객체 스스로 자신의 데이터를 책임져야 한다. 자신이 소유하고 있지 않은 데이터를 이용해 작업을 처리하는 객체에게 어떻게 연관성 높은 작업들을 할당할 수 있겠는가? 객체는 자신의 데이터를 스스로 처리하는 자율적인 존재여야 한다.
절차지향과 객체지향
수정하기 전의 코드는 Theater의 enter 메서드 안에서 Audience와 TicketSeller로 부터 Bag과 TicketOffice를 가져와 관람객을 입장시키는 절차를 구현했다. 모든 처리는 Theater의 enter 메서드 안에 존재했었다.
이 관점에서 Thater의 enter 메서드는 프로세스(Process)이며 Audience, TicketSeller, Bag, TicketOffice는 데이터(Data)다. 이처럼 프로세스와 데이터를 별도의 모듈에 위치시키는 방식을 절차적 프로그래밍(Procedural Programming)이라고 부른다.
변경하기 쉬운 설계는 한 번에 하나의 클래스만 변경할 수 있는 설계다. 절차적 프로그래밍은 프로세스가 필요한 모든 데이터에 의존해야 한다는 근본적인 문제점 때문에 변경에 취약할 수 밖에 없다.
해결 방법은 자신의 데이터를 스스로 처리하도록 프로세스의 적절한 단계를 Audience와 TicketSeller로 이동시키는 것이다. 이처럼 데이터와 프로세스가 동일한 모듈 내부에 위치하도록 프로그래밍하는 방식을 객체지향 프로그래밍(Object-Oriented Programming)이라고 부른다.
훌륭한 객체지향 설계의 핵심은 캡슐화를 이용해 의존성을 적절히 관리함으로써 객체 사이의 결합도를 낮추는 것이다. 일반적으로 객체지향이 절차지향에 비해 변경에 좀 더 유연하다고 말하는 이유가 바로 이것이다.
책임의 이동
두 방식 사이에 근본적인 차이를 만드는 것은 책임의 이동(shift of responsibility)이다. 여기서는 '책임'을 기능을 가리키는 객체지향 세계의 용어로 생각해도 된다.
절자적 프로그래밍 방식은 책임이 Theater에 집중돼 있다.
객체지향 프로그래밍 방식은 책임이 개별 객체로 이동한 것이다. 이것이 바로 책임의 이동이 의미하는 것이다.
각 객체는 자신을 스스로 책임진다. 객체지향 애플리케이션은 스스로 책임을 수행하는 자율적인 객체들의 공동체를 구성함으로써 완성된다.
객체지향 설계의 핵심은 적절한 객체에 적절한 책임을 할당하는 것이다. 객체는 다른 객체와의 협력이라는 문맥 안에서 특정한 역할을 수행하는 데 필요한 적절한 책임을 수행해야 한다.
설계를 어렵게 만드는 것은 의존성이라는 것을 기억하라. 해결 방법은 불필요한 의존성을 제거함으로써 객체 사이의 결합도를 낮추는 것이다. 불필요한 세부사항을 객체로 캡슐화하는 것은 객체의 자율성을 높이고 응집도 높은 객체들의 공동체를 창조할 수 있게 한다.
더 개선할 수 있다.
public class Audience {
private Bag bag;
private Audience(Bag bag) {
this.bag = 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();
}
}
}Bag에 문제가 있는걸 알 수 있을 것이다. Bag를 자율적인 존재로 바꿔보자.
public class Bag {
private Long amount;
private Invitation invitation;
private Ticket ticket;
public Bag(Invitation invitation, long amount) {
this.invitation = invitation;
this.amount = amount;
}
private boolean hasInvitation() {
return invitation != null;
}
private void setTicket(Ticket ticket) {
this.ticket = ticket;
}
private void minusAmount(Long amount) {
this.amount -= amount;
}
public Long hold(Ticket ticket) {
if (hasInvitation()) {
setTicket(ticket);
return 0L;
} else {
setTicket(ticket);
minusAmount(ticket.getFee());
return ticket.getFee();
}
}
}Bag의 구현을 캡슐화시켰으니 이제 Audience를 Bag의 구현이 아닌 인터페이스에만 의존하도록 수정하자.
public class Audience {
private Bag bag;
private Audience(Bag bag) {
this.bag = bag;
}
public Long buy(Ticket ticket) {
return bag.hold(ticket);
}
}TicketSeller 역시 TicketOffice의 자율권을 침해한다. 아래 코드에서 알 수 있듯이 현재의 TicketSeller는 TicketOffice에 있는 Ticket을 마음대로 꺼내서는 자기 멋대로 Audience에게 팔고 Audience에게 받은 돈을 마음대로 TicketOffice에 넣어버린다.
public class TicketSeller {
private TicketOffice ticketOffice;
public TicketSeller(TicketOffice ticketOffice) {
this.ticketOffice = ticketOffice;
}
public void sellTo(Audience audience) {
ticketOffice.plusAmount(audience.buy(ticketOffice.getTicket()));
}
}TicketOffice의 자율권을 찾아주자.
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 void sellTicketTo(Audience audience) {
plusAmount(audience.buy(getTicket()));
}
public Ticket getTicket() {
return tickets.remove(0);
}
public void minusAmount(Long amount) {
this.amount -= amount;
}
public void plusAmount(Long amount) {
this.amount += amount;
}
}이제 TicketSeller가 TicketOffice의 구현이 아닌 인터페이스에만 의존하게 되었다.
public class TicketSeller {
private TicketOffice ticketOffice;
public TicketSeller(TicketOffice ticketOffice) {
this.ticketOffice = ticketOffice;
}
public void sellTo(Audience audience) {
ticketOffice.sellTicketTo(audience);
}
}이 변경은 처음에 생각했던 것보다 만족스럽지 않다. 그 이유는 TicketOffice와 Audience 사이에 의존성이 추가됐기 때문이다.
변경 전에는 존재하지 않았던 새로운 의존성이 추가된 것이다. 의존성의 추가는 높은 결합도를 의미하고, 높은 결합도는 변경하기 어려운 설계를 의미한다.
TicketOffcie의 자율성은 높였지만 전체 설계의 관점에서는 결합도가 상승했다.
이 작은 예제를 통해 두 가지 사실을 알 수 있다.
첫째, 어떤 기능을 설계하는 방법은 한 가지 이상일 수 있다.
둘째, 동일한 기능을 한 가지 이상의 방법으로 설계할 수 있기 때문에 결국 설계는 트레이드오프의 산물이다. 어떤 경우에도 모든 사람들을 만족시킬 수 있는 설계를 만들 수는 없다.
그래, 거짓말이다!
앞에서 실생활의 관람객과 판매자가 스스로 자신의 일을 처리하기 때문에 코드에서의 Audience와 TicketSeller 역시 스스로 자신을 책임져야 했다고 말했던 것을 기억하는가? 이것은 우리가 세상을 바라보는 직관과도 일치한다. 따라서 이 직관에 따르는 코드는 이해하기가 더 쉬운 경향이 있다.
현실에서는 수동적인 존재라고 하더라도 일단 객체지향의 세계에 들어오면 모든 것이 능동적이고 자율적인 존재로 바뀐다. 이처럼 능동적인 자율적인 존재로 소프트웨어 객체를 설계하는 원칙을 가리켜 의인화(anthropomorphism)라고 부른다.
훌륭한 객체지향 설계란 소프트웨어를 구성하는 모든 객체들이 자율적으로 행동하는 설계를 가리킨다.
04. 객체지향 설계
설계가 왜 필요한가
좋은 설계란 무엇일까? 우리가 짜는 프로그램은 두 가지 요구사항을 만족시켜야 한다.
오늘 완성해야 하는 기능을 구현하는 코드를 짜야 하는 동시에 내일 쉽게 변경할 수 있는 코드를 짜야 한다.
변경을 수용할 수 있는 설계가 중요한 이유는 요구사항이 항상 변경되기 때문이다.
객체지향 설계
훌륭한 객체지향 설계란 협력하는 객체 사이의 의존성을 적잘하게 관리하는 설계다. 객체가 실행되는 주변 환경에 강하게 결합될수록 변경하기 어려워진다. 객체 간의 의존성은 애플리케이션을 수정하기 어렵게 만드는 주범이다.
