오브젝트 - 01 객체, 설계

프로그래밍 패러다임

패러다임 : 한 시대의 사회 전체가 고유하는 이론이나 방법, 문제의식 등의 체계

패러다임의 전환 : 과거의 패러다임이 새로운 패러다임에 의해 대체됨으로써 정상과학의 방향과 성격이 변하는 것

프로그래밍 패러다임 : 어느 성숙한 개발자 공동체에 의해 수용된 프로그래밍 방법과 문제 해결 방법, 프로그래밍 스타일

→ 어떤 프로그래밍 패러다임을 사용하느냐에 따라 문제를 바라보는 관점과 프로그램을 작성하는 방법이 달라진다

.

티켓 판매 어플리케이션 구현

문제

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

• Theater가 관람객과 판매원의 일을 수행하고 있다
  • 각 객체가 수동적이다
  • 각 객체의 세부 사항을 너무 많이 알고 있다 (디미터법칙)
  • 관람객이나 판매원이 변경되면 Theater도 변경되야 한다 (SRP 위반)
  • Theater는 너무 많은 클래스에 의존하고 있다.

→ 변경에 취약하고 이해하기 어려운 코드

개선

public class Theater {
  private TicketSeller ticketSeller;
  
  public Theater(TicketSeller ticketSeller) {
    this.ticketSeller = ticketSeller;
  }
  
  public void enter(Audience audience) {
    ticketSeller.sellTo(audience)
  }
}

• Theater는 TicketSeller의 인터페이스에만 의존한다.

→ 인터페이스만을 공개하는 것은 결합도를 낮추고 변경하기 쉽게 한다

→ TicketSeller의 내부 구현이 캡슐화되어 있다.

→ facade 패턴이 적용되었다.

결론

• 각 객체가 스스로 문제를 해결하도록 변경함으로써 코드는 변경이 용이하고 이해 가능하다
• 객체 내부 상태를 캡슐화하고 객체 간에 오직 메시지를 통해서만 상호작용 하도록 만든다

→ 응집도가 높다(밀접하게 연관된 작업만을 수행하고 연관성 없는 작업은 다른 객체에게 위임하는 객체)

• 현실에서는 수동적인 존재라고 하더라도 객체지향에선 능동적이고 자율적인 존재(의인화)
• 좋은 설계란 기능을 온전히 수행하면서 내일의 변경을 매끄럽게 수용할 수 있는 설계