럿고의 개발 노트
Chapter01. 객체, 설계 본문
오브젝트 - 코드로 이해하는 객체지향 설계
Chapter01. 객체, 설계
01. 티켓 판매 애플리케이션 구현하기
소극장의 이벤트를 기획했다. 추첨을 통해 선정된 관람객에게 공연을 무료로 관람할 수 있는 초대장을 발송하는 것이다.
조건이 있는데, 입장 시 이벤트에 당첨된 관람객과 그렇지 못한 관람객은 다른 방식으로 입장시켜야 한다.
이벤트 당첨 관람객은 초대장을 티켓으로 교환한 후에 입장할 수 있으며, 당첨되지 않은 관람객은 티켓을 구매해야만 입장할 수 있다.
따라서 관람객을 입장시키기 전 이벤트 당첨 여부 확인과 이벤트 당첨자가 아니면 티켓을 판매한 후에 입장시켜야 한다.
Invitation Class - 초대장
when: 공연을 관람할 수 있는 초대일자
import java.time.LocalDateTime;
public class Invitation {
private LocalDateTime when;
}- Ticket Class - 티켓
fee는 티켓 가격
public class Ticket {
private Long fee;
public Long getFee() {
return fee;
}
}- Bag Class - 소지품 가방
amount: 관람객이 가지고 있는 현금invitation: 관람객이 가지고 있는 초대장ticket: 관람객이 가지고 있는 초대장- 생성자는 초대장과 현금을 같이 가지고 있는 것과, 초대장은 없고 현금만 가지고 있는 것으로 분류
hasInvitation(): 초대장을 가지고 있는지 확인minusAmount(): 티켓을 구매한 경우 가지고 있는 현금으로 계산하기 위함
public class Bag {
private Long amount;
private Invitation invitation;
private Ticket ticket;
public Bag(long amount){
this(amount, null);
}
public Bag(Long amount, Invitation invitation) {
this.amount = amount;
this.invitation = invitation;
}
public boolean hasInvitation(){
return invitation != null;
}
public void setTicket(Ticket ticket) {
this.ticket = ticket;
}
public void minusAmount(Long amount){
this.amount -= amount;
}
}- Audience Class - 관람객
bag: 위에서 정의한 소지품 가방을 의미
public class Audience {
private Bag bag;
public Audience(Bag bag) {
this.bag = bag;
}
public Bag getBag() {
return bag;
}
}- TicketOffice Class - 티켓 판매 사무실
amount: 가지고 있는 현금tickets: 가지고 있는 티켓getTicket(): 티켓을 판매할때 가지고 있는 티켓을 주기 위한 메소드plusAmount(): 관람객이 티켓을 구매할때 계산하기 위한 메소드
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
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 plusAmount(Long amount) {
this.amount += amount;
}
}- TicketSeller - 티켓 판매자
ticketOffice: 티켓판매사무실
public class TicketSeller {
private TicketOffice ticketOffice;
public TicketSeller(TicketOffice ticketOffice) {
this.ticketOffice = ticketOffice;
}
public TicketOffice getTicketOffice() {
return ticketOffice;
}
}- Theater Class - 극장
ticketSeller: 티켓을 판매하는 사람enter(): 극장에 입장시키기 위한 메서드- 1번째 조건문 : 소지품에 초대장이 있다면 초대장과 티켓을 교환
else조건문 : 소지품에 초대장이 없다면, 티켓을 현금으로 계산
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. 무엇이 문제인가?
- 로버트 마틴이 소프트웨어 모듈이 가져야 하는 세 가지 기능을 살펴 보겠다.
- 실행 중에 제대로 동작하는 것
2, 변경을 위해 존재 - 코드를 읽는 사람과 의사소통하는 것
- 실행 중에 제대로 동작하는 것
예상을 빗나가는 코드
Theater Class의enter()는 관람객과 판매원이 소극장의 통제를 받는 수동적인 존재라는 점이 문제이다.- 코드를 현실적으로 생각한다면, 관람객의 가방을 마음대로 열어보고 초대장을 확인하고 돈을 마음대로 가져가는 것이다.
- 관람객에게 티켓을 판매하거나 초대장을 확인하는 일을
TicketSeller가 하는 것이 아니라Theater가 한다는 점이다. - 코드를 이해하기 위해서는 여러 가지 세부적인 내용들을 한꺼번에 기억하고 있어야 한다는 점이다. 즉, 하나의 클래스나 메서드에서 너무 많은 세부사항을 다루기 때문에 가독성이 떨어진다.
변경에 취약한 코드
Audience와TicketSeller를 변경할 경우Theater도 함께 변경해야 한다.- 이것은 객체 사이의 의존성과 관련된 문제이며, 의존성이 변경과 관련돼어 있고 의존성은 변경에 대한 영향을 암시한다.
- 그러나 객체 사이의 의존성을 완전히 없애는 것이 정답은 아니다. 객체지향 설계는 서로 의존하면서 협력하는 객체들의 공동체를 구축하는 것이다.
- 따라서 우리의 목표는 애플리케이션의 기능을 구현하는 데 필요한 최소한 의존성만 유지하고 불필요한 의존성을 제거하는 것이다.
- 또한 객체 사이의 의존성이 과한 경우를 가리켜 결합도가 높다고 말한다. 반대로 객체들이 합리적인 수준으로 의존할 경우에는 결합도가 낮다고 말한다.
- 결합도는 의존성과 관련돼 있기 때문에 결합도 역시 변경과 관련이 있다. 두 객체 사이의 결합도가 높으면 높을수록 함께 변경될 확률도 높아지기 때문에 변경하기 어려워진다.
- 따라서 설계의 목표는 객체 사이의 결합도를 낮춰 변경이 용이한 설계를 만드는 것이어야 한다.
03. 설계 개선하기
- 해결 방법은 간단하다.
Theater가Audience와TicketSeller에 관해 너무 세세한 부분까지 알지 못하도록 정보를 차단하면 된다. - 즉, 관람객과 판매원을 자율적인 존재로 만들면 되는 것이다.
자율성을 높이자
public class Theater {
private TicketSeller ticketSeller;
public Theater(TicketSeller ticketSeller) {
this.ticketSeller = ticketSeller;
}
public void enter(Audience audience){
ticketSeller.sellTo(audience);
}
}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);
}
}
}getTicketOffice()가 제거된 것에 주목해야 한다. 이렇게 되면 외부에서ticketOffice에 직접 접근 할수가 없어서ticketOffice는 오직TicketSeller만 가능하게 된다.- 따라서
TicketSeller가 직접 티켓을 꺼내고 판매요금을 적립해야 한다. - 이와 같이 개념적이나 물리적으로 객체 내부의 세부적인 사항을 감추는 것을 캡슐화라고 부른다. 캡슐화의 목적은 변경하기 쉬운 객체를 만드는 것이다. 캡슐화를 통해 객체 내부로의 접근을 제한하면 객체와 객체 사이의 결합도를 낮출 수 있기 때문에 설계를 좀 더 쉽게 변경할 수 있다.
Theater는TicketSeller의 인터페이스에만 의존하게 된다.TicketSeller가 내부에TicketOffice인스턴스를 포함하고 있다는 사실은 구현의 영역에 속한다.- 객체를 인터페이스와 구현으로 나누고 인터페이스만을 공개하는 것은 객체 사이의 결합도를 낮추고 변경하기 쉬운 코드를 작성하기 위해 따라야 하는 가장 기본적인 설계 원칙이다.
public class Audience {
private Bag bag;
public Audience(Bag bag) {
this.bag = bag;
}
public Long buy(Ticket ticket) {
if (bag.hasInvitation()) {
bag.setTicket(ticket);
return 0L;
} else {
bag.minusAmount(ticket.getFee());
bag.setTicket(ticket);
return ticket.getFee();
}
}
}public class TicketSeller {
private TicketOffice ticketOffice;
public TicketSeller(TicketOffice ticketOffice) {
this.ticketOffice = ticketOffice;
}
public void sellTo(Audience audience) {
ticketOffice.plusAmount(audience.buy(ticketOffice.getTicket()));
}
}- 이 코드도 똑같이
getter가 사라졌기 때문에 외부에서 관람객이 자신의 가방을 열어 볼수 없게 되었기 때문에 캡슐화할 수 있게 되었다.
무엇이 개선됐는가
- 문제점
- 코드를 현실적으로 생각한다면, 관람객의 가방을 마음대로 열어보고 초대장을 확인하고 돈을 마음대로 가져가는 것이다.
Audience와TicketSeller를 변경할 경우Theater도 함께 변경해야 한다.
- 개선 방법
- 관람객의 가방을 관람객 스스로 관리하도록 변경하였다.
- 관람객과 티켓판매원을 변경해도 극장은 변경할 필요가 없어졌다. 가방이 아니라 지갑을 소지하도록 코드를 변경하고 싶다면 관람객만 변경하면 된다.
어떻게 한 것인가
Bag에 대한 모든 부분을Audience로 옮겼으며TicketOffice에 대한 모든 부분을TicketSeller로 옮겼다.- 즉, 자기 자신의 문제를 스스로 해결하도록 코드를 변경한 것이다.
캡슐화와 응집도
- 객체 내부의 상태를 캡슐화하고 객체 간에 오직 메시지를 통해서만 상호작용하도록 만드는 것이다.
- 밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 위임하는 객체를 가리켜 응집도가 높다고 말한다. 즉, 자신의 데이터를 스스로 처리하는 자율적인 객체를 만들면 결합도를 낮출 수 있을뿐더라 응집도를 높일 수 있다.
- 외부의 간섭을 최대한 배제하고 메시지를 통해서만 협력하는 자율적인 객체들의 공동체를 만드는 것이 훌륭한 객체지향 설계를 얻을 수 있는 지름길인 것이다.
절차지향과 객체지향
절차지향
- 수정전 코드의 관점에서 볼 때는
enter()는 프로세스이며Audience,TicketSeller,Bag,TicketOffice는 데이터이다. 이처럼 프로세스와 데이터를 별도의 모듈에 위치시키는 방식을 절차적 프로그래밍이다. - 단점은 가독성이 떨어지며, 데이터의 변경으로 인한 영향을 지역적으로 고립시키기 어렵다는 것이다.
객체지향
- 변경하기 쉬운 설계는 한 번에 하나의 클래스만 변경할 수 있는 설계이다. 데이터와 프로세스가 동일한 모듈 내부에 위치하도록 프로그래밍하는 방식을 객체지향 프로그래밍이라고 부른다.
- 훌륭한 객체지향 설계의 핵심은 캡슐화를 이용해 의존성을 적절히 관리함으로써 객체 사이의 결합도를 낮추는 것이다.
- 객체지향 코드는 자신의 문제를 스스로 처리해야 한다는 우리의 예상을 만족시켜주기 때문에 이해하기 쉽고, 객체 내부의 변경이 객체 외부에 퍼급도지 않도록 제어할 수 있기 때문에 변경하기가 수월하다.
책임의 이동
- 수정전 코드는 책임이
Theater에 집중되어 있다. - 그에 반해 수정 후 코드는 제어 흐름이 각 객체에 적절하게 분산되어 있다. 수정하면서
Theater에 몰려 있던 책임을 각 객체로 이동한 것이다. - 즉, 객체지향 설계에서는 독재자가 존재하지 않고 각 객체에 책임이 적절하게 분배되며, 각 객체는 자신을 스스로 책임진다.
- 설계를 어렵게 만드는 것은 의존성이라는 것을 기억하라. 해결 방법은 불필요한 의존성을 제거함으로써 객체 사이의 결합도를 낮추는 것이다. 예제에서 결합도를 낮추기 위해 사용한 방법은 캡슐화를 이용했다.
- 결과적으로 불필요한 세부사항을 객체 내부로 캡슐화하는 것은 객체의 자율성을 높이고 응집도 높은 객체들의 공동체를 창조할 수 있게 한다.
- 불필요한 세부사항을 캡슐화하는 자율적인 객체들이 낮은 결합도와 높은 응집도를 가지고 협력하도록 최소한의 의존성만을 남기는 것이 훌륭한 객체지향 설계다.
더 개선할 수 있다.
Audience는 자율적인 존재인데,Bag은 자기 자신이 책임 지지 않고Audience에 의해 끌려다니는 수동적인 존재이다.
public class Bag {
private Long amount;
private Invitation invitation;
private Ticket ticket;
public Bag(long amount){
this(amount, null);
}
public Bag(Long amount, Invitation invitation) {
this.amount = amount;
this.invitation = invitation;
}
public Long hold(Ticket ticket){
if(hasInvitation()){
this.ticket = ticket;
return 0L;
}else{
this.ticket = ticket;
minusAmount(ticket.getFee());
return ticket.getFee();
}
}
private boolean hasInvitation(){
return invitation != null;
}
private void minusAmount(Long amount){
this.amount -= amount;
}
}public class Audience {
private Bag bag;
public Audience(Bag bag) {
this.bag = bag;
}
public Long buy(Ticket ticket) {
return bag.hold(ticket);
}
}이런식으로 수정한다면
setter가 제거되며Bag에 관련된 상태와 행위는 모두Bag에서 처리하게 되었다. 따라서hasInvitation,minusAmount가private가 되었다.TicketSeller도 역시TicketOffice의 자율권을 침해한다. 마음대로 티켓을 뽑고 자기 마음대로 티켓을Audience에게 건네주며 돈도 마음대로 넣어버린다.
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
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()));
}
private Ticket getTicket() {
return tickets.remove(0);
}
private void plusAmount(Long amount) {
this.amount += amount;
}
}public class TicketSeller {
private TicketOffice ticketOffice;
public TicketSeller(TicketOffice ticketOffice) {
this.ticketOffice = ticketOffice;
}
public void sellTo(Audience audience) {
ticketOffice.sellTicketTo(audience);
}
}- 그러나 이런식으로 구현하게 된다면
TicketOffice와Audience사이에 의존성이 없었는데, 의존성이 추가되었다. 의존성의 추가는 높은 결합도를 의미하며, 높은 결합도는 변경하기 어려운 설계를 의미한다.
예제 정리
- 어떤 기능을 설계하는 방법은 한 가지 이상일 수 있다.
- 동일한 기능을 한 가지 이상의 방법으로 설계할 수 있기 때문에 결국 설계는 트레이드오프 산물이다. 어떤 경우에도 모든 사람들을 만족시킬 수 있는 설계를 만들 수 없다.
그래, 거짓말이다!
- 비록 현실에서는 수동적인 존재라고 하더라도 일단 객체지향의 세계에 들어오면 모든 것이 능동적이고 자율적인 존재로 바뀐다. 레베카 워프스브록은 이처럼 능동적이고 자율적인 존재로 소프트웨어 객체를 설계하는 원칙을 가리켜 의인화라고 부른다.
- 훌륭한 객체지향 설계란 소프트웨어를 구성하는 모든 객체들이 자율적으로 행동하는 설계를 가리킨다. 그 대상이 비록 실계에서는 생명이 없는 수동적인 존재라고 하더라도 객체지향의 세계로 넘어오는 순간 그들은 생명과 지능을 가진 싱싱한 존재로 다시 태어난다.
04. 객체지향 설계
설계가 왜 필요한가.
- 설계는 코드를 작성하는 매 순간 코드를 어떻게 배치할 것인지를 결정하는 과정에서 나온다. 즉, 설계는 코드 작성의 일부이며 코드를 작성하지 않고서는 검증할 수 없다.
- 좋은 설계란 오늘 요구하는 기능을 온전히 수행하면서 내일의 변경을 매끄럽게 수용할 수 있는 설계다.
- 또한 변경을 수용할 수 있는 설계가 중요한 이유는 요구사항이 항상 변경되기 때문이며, 코드를 변경할때 버그가 추가될 가능성이 높기 때문이다.
객체지향 설계
- 변경 가능한 코드란 이해하기 쉬운 코드이다.
- 세상에 존재하는 모든 자율적인 존재처럼 객체 역시 자신의 데이터를 스스로 책임지는 자율적인 존재이다.
- 애플리케이션의 기능은 객체들 간의 상호작용을 통해 구현되며, 객체들 사이의 상호작용은 객체 사이에 주고 받는 메시지로 표현된다.
- 메시지를 전달하기 위해 두 객체를 결합시키고 이 결합이 객체 사이의 의존성을 만든다.
- 즉, 휼륭햔 객체지향 설계란 협력하는 객체 사이의 의존성을 적절하게 관리하는 설계다.
Comments