Chapter 1. 객체, 설계

조영호님의 오브젝트를 읽고 제 머릿속에 있는 내용들을 정리하며 작성한 글입니다.

 

---

변경에 취약한 코드

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();
            
            // 관람객이 갖고 있는 현금(amount)를 받아 티켓 교환
            audience.getBag().minusAmount(ticket.getFee());
            ticketSeller.getTicketOffice().plusAmount(ticket.getFee());
            audience.getBag().setTicket(ticket);
        }
    }
}

위 코드는 관람객의 가방에 초대장이 있으면 티켓을 교환하여 관람객에게 주고, 초대장이 없다면 관람객의 가방안에 있는 현금으로 티켓을 구매한 뒤 티켓을 주는 코드이다.

 

이 코드의 문제점은 다음과 같다.

1. 티켓 판매원과 관람객간의 협력과정을 Theater가 주도하고 감시한다.
2. 객체 간 결합도가 너무 높아서 코드를 이해하기 힘들고 Audience나 TicketSeller 에 변화가 발생하는 경우 Theater 코드도 영향을 받는다.
   
   Audience가 Bag 클래스가 없어진다면? 현금(amount)이 아닌 신용카드 결제도 추가된다면? 등등의 변화가 발생하면 Theater 코드도 수정해주어야 한다.

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

 

그리고 💡 캡슐화가 필요하다.

 

Theater는 Audience 객체의 Bag 객체에도 접근할 수 있으며 TicketSeller의 TicketOffice에도 접근할 수 있다.

 

이러한 부분을 private 제어자를 통해 자신이 의존하는 객체는 자신이 처리할 수 있어야 객체간 결합도를 낮출 수 있다.

 

1️⃣ 캡슐화를 통한 결합도 감소

public class Theater {
    private TicketSeller ticketSeller;

    public Theater(TicketSeller ticketSeller) {
        this.ticketSeller = ticketSeller;
    }

    public void enter(Audience audience) {
        ticketSeller.sellTo(audience);
    }
}

 

변경된 코드는 위와 같다.

 

Theater는 관람객의 가방에 무엇이 있는지, 초대권을 교환하는지 등등을 신경쓰지 않는다.

 

판매원이 관람객에게 어떠한 형태로든 티켓을 판매했으면 입장시켜주는 역할만 수행하게 된다.

 

이전 코드에는 Bag TicketOffice Ticket amount fee 등 다양한 객체와 변수와 결합되어 있었지만,

 

수정된 코드에서는 결합도가 많이 낮아졌음을 한눈에 알 수 있다.

 

public class TicketSeller {
    private TicketOffice ticketOffice;

    public TicketSeller(TicketOffice ticketOffice) {
        this.ticketOffice = ticketOffice;
    }

    public void sellTo(Audience audience) {
        if (audience.getBag().hasInvitation()) {
            Ticket ticket = this.getTicketOffice().getTicket();
            audience.getBag().setTicket(ticket);
        } else {
            Ticket ticket = this.getTicketOffice().getTicket();
            audience.getBag().minusAmount(ticket.getFee());
            this.getTicketOffice().plusAmount(ticket.getFee());
            audience.getBag().setTicket(ticket);
        }
    }
}

 

티켓을 판매하는 역할은 판매원과 관람객 사이에서 이루어지기 때문에

 

TicketSeller안에 메서드로서 추가해주게 되었다.

 

다만, 위 코드 역시 TicketSeller가 Audience의 Bag에 접근하기 때문에 한번더 캡슐화를 통해 결합도를 낮출 수 있다.

 

 

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.setTicket(ticket);
            bag.minusAmount(ticket.getFee());
            return ticket.getFee();
        }
    }

}

이제 관람객이 스스로 자신의 Bag와 메세지를 주고 받고 관리하는 주체가 되었다.

 

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는 TicketOffice의 필드인 Ticket을 마음대로 사용하고 있으므로 요청하는 방식으로 바꿔보자.

 

public class TicketOffice {
    private Long amount;
    private List<Ticket> tickets = new ArrayList<>();

	...
    
    public void sellTicketTo(Audience audience) {
        plusAmount(audience.buy(getTicket()));
    }
}

TicketOffice는 자신의 ticket은 자신이 처리한다.

 

🚨 대신, TicketOffice는 Audience라는 객체를 추가적으로 의존하게 되긴 했다.

 

public class TicketSeller {
    private TicketOffice ticketOffice;

    public TicketSeller(TicketOffice ticketOffice) {
        this.ticketOffice = ticketOffice;
    }

    public void sellTo(Audience audience) {
        ticketOffice.sellTicketTo(audience);
    }
}

TicketSeller는 TicketOffice에게 티켓을 관람객에게 팔것을 요청한다.

 

 

이제 Audience가 Bag의 변수를 변경하지 말고, Bag에게 요청을 하는 방식으로 한번 더 리팩토링 해보자.

public class Bag {
    private Long amount;
    private Invitation invitation;
    private Ticket ticket;

    public Bag(long amount) {
        this(null, amount);
    }

    public Bag(Invitation invitation, long amount) {
        this.invitation = invitation;
        this.amount = amount;
    }

    public Long hold(Ticket ticket) {
        if (hasInvitation()) {
            setTicket(ticket);
            return 0L;
        } else {
            setTicket(ticket);
            minusAmount(ticket.getFee());
            return ticket.getFee();
        }
    }

    private boolean hasInvitation() {
        return invitation != null;
    }

    public boolean hasTicket() {
        return ticket != null;
    }

    private void setTicket(Ticket ticket) {
        this.ticket = ticket;
    }

    private void minusAmount(Long amount) {
        this.amount -= amount;
    }

    private void plusAmount(Long amount) {
        this.amount += amount;
    }
}

이제 Bag이 자신의 필드는 자신이 관리하게끔 되었다.

 

public class Audience {
    private Bag bag;

    public Audience(Bag bag) {
        this.bag = bag;
    }

    public Long buy(Ticket ticket) {
        return bag.hold(ticket);
    }

}

관람객은 Bag 객체에게 티켓을 갖고 있을 것을 요청하는 코드가 되었다.

 

 

💡 이제 관람객이 가방에서 지갑으로 바뀌었든, 비닐봉지로 바뀌었든 TicketSeller는 신경쓰지 않는다.

 

객체 자신과 깊게 결합되어 있는 객체는, 제 3자 객체가 아닌 스스로 처리하게끔 생각하면 위와 같은 리팩토링을 할 수 있다.

 

이와 같이 밀접하게 연관되어 있는 작업을 자신이 처리하는 경우를 응집도가 높다고 말한다.

 

즉, 객체간 결합도를 낮추고 응집도를 높이는 방식으로 개선시킨 것이라고 할 수 있겠다.

 

하나의 객체는 하나의 책임을 가져야 한다는 SOLID의 SRP 와 

 

변화에는 닫혀있고 확장에는 열려있어야 한다는 OCP 법칙을 지키게끔 개선했다고 생각이든다.

 

객체 지향의 대척점에 있다고 생각할 수 있는 절차적 프로그래밍은 필요한 모든 데이터를 의존해야한다는 점에서 변화에 매우 취약하다고 볼 수 있다.

 

반면에, 객체 지향 프로그래밍은 💡 캡슐화를 이용해 객체 간 결합도를 낮춤으로서 변화에 유연하고 영향력이 넓게 전파되는 것을 막을 수 있게 되었다.

 

🚨 리팩토링 하는 과정에서 의존성이 없던 객체들 간의 결합도 생긴 경우가 있었는데, 모든 객체간의 결합도를 낮추는 것은 불가능하고 어떤 결합이 더 유용한지 판단해서 결정하는 것은 개발자의 몫이 된다.