[책 오브젝트] CHAPTER 1 - 객체, 설계

좋은 설계란?

소프트웨어 모듈의 목적 (로버트 마틴)

• 동작해야함
• 간단한 작업으로도 변경이 가능해야함 (저자가 강조하는 부분)
• 이해하기 쉬워야함 (두번째로 강조)

좋지 않은 설계(entry method 확인)

public class Theater {
    private TicketSeller ticket Seller;

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);
        }
    }
}

• Theater이 TicketSeller, TicketOffice, Audience, Bag, Ticket에 의존하고 있음
• 의존성이 있는 특정 객체를 수정하면 Theater 코드도 수정해야 함 → 변경에 취약함
  • getBag() → 만약 Bag이 지갑이 된다면?
  • 셀러가 Office 밖에서 티켓을 판다면?

객체간 의존성, 결합도를 낮추고 자율성을 부여하자

소극장이 고객의 가방을 꺼내서 돈을 티켓으로 바꾸는 행위를 맡으면 X

• 사람이 가방을 꺼내 돈을 낸다
• ticket seller가 티켓 처리 진행

책임의 이동 (좋은 설계)

Theater에 집중되어있는 책임을 ticket seller, audience 등으로 분산하여 각 객체 스스로가 책임을 지게함

• 의존성 제거 → 결합도 낮춤
• 세부사항을 객체 내부로 감춰 캡슐화 → 객체의 자율성 높임, 응집도 높임

vs 절차지향이라면?

• theater에서 책임을 다 지는 코드
  • 결합도가 높아 변경이 어려움
• 데이터와 책임, 프로세스(의미적)가 별도의 객체에 위치하고 있음

의인화

소프트웨어 세계에선 모든것이 능동적이고 자율적인 존재임

→ 의인화 해야한다 (bag, theater, ticket office)
→ bag, theater 등도 능동적으로 행동하고 움직이는 생물처럼 생각해야함

모든 사람을 만족시키는 설계는 없다

• 캡슐화를 진행하다 의존성이 오히려 높아지는 경우 등
• 적절한 트레이드 오프로 결정해야함

좋은 설계란

• 오늘 완성해야하는 기능을 구현하는 코드를 짜는것
• 내일 쉽게 변경할 수 있는 코드를 짜는 것
  • 협력하는 객체간 의존성을 적절하게 조절해야함
• 결국 로버트 마틴의 소프트웨어 모듈의 목적 3가지를 만족할 수 있어야한다는 뜻

---

ps. 요새 개발을 하며 실력, 지식의 부족함을 많이 느끼고 있다. 관련 공부가 필요하다고 느끼기 때문에 관련 도서를 읽으며 챕터를 정리하고자 한다. 첫 책은 오브젝트(조영호 저)로 선택했다