Open wonslee opened 8 months ago
저는 확장을 위해서 TicketSeller
가 필요하다고 생각해요! 제가 생각한 두 객체의 역할은 아래와 같습니다.
TicketSeller
: 관람객이 지불한 금액을 정산TicketOffice
: 발급할 티켓과 판매금액 저장소만약 할인 제도가 추가된다면 금액 정산관련 로직이 복잡해질 것 같아요! 이 때 TicketOffice
객체 하나만 뒀다면 다른 객체에 비해 맡은 역할이 너무 많아질거 같아 TicketSeller
가 필요해보입니다!
저는 민우님처럼 분리를 하는게 맞다고 생각합니다.
1장에서 제시한 요구사항만을 생각한다면 원석님처럼 TicketOffice
에서 전부 처리하는게 타당해 보일수 있으나
민우님이 예시로 든 정산관련로직 혹은 티켓을 구매하는데 추가적인 로직이 필요할 경우 TicketOffice
에서 전부 처리하기에는 객체의 역할이 비대해지는 소위 전지전능한 객체 (god object
)가 만들어질수도 있을것 같다는 생각이 듭니다.
1장의 마지막 스텝의 경우, 책에서도 TicketOffice
의 자율성보다 Audience
에 대한 결합도를 낮추는 게 더 나을 것 같다는 결론이 나온 만큼 저도 그 부분에 대해 동일하게 생각합니다.
TicketSeller
와 TicketOffice
의 책임에 대해서는, 저는 실제 상황을 생각했을 때 TicketOffice
를 티켓 부스, TicketSeller
를 티켓 판매원으로 생각해서 어색하게 다가오지는 않았는데, 객체를 어디까지 분리하는 것이 적당한 지에 대해서는 항상 고민하게 되는 것 같아요.
지금 1장의 상황에서는 TicketOffice
에 모든 책임을 지우는 데 무리가 없을 수 있지만, 반대로 실제의 어떤 공연장(극장)에서는 초대권 관객과 일반 관객을 나눠서 응대하는 상황도 있다는 걸 고려해보면 TicketSeller
의 객체도 분리가 필요한 시점이 생길 수 있지 않을까 하는 생각도 듭니다.
결국 설계하고자 하는 규모에 따라 객체를 규정하게 될 것 같은데 현재 로직에서 TicketOffice
객체만으로도 충분하다는 판단이 들되, 추후에 필요시 TicketSeller
의 역할 분리가 용이하다면 원석님이 말씀하신 의인화된 TicketOffice
로도 충분하지 않을까요?
마지막 스텝의 TicketOffice 와 TicketSeller 에 대해 여러분들의 의견이 궁금해요.
저는 이전 스텝의 코드가 조금 더 좋은 것 같긴 합니다.
TicketSeller에서 ticketOffice를 한번 숨긴다고 해서 응집도가 크게 올라가는 것 같지 않다고 생각했어요.
조금 엉뚱한 생각이지만... TicketSeller를 없애고 TicketOffice에게 책임을 몰아주면 어떨까요?
마지막에 나온 의인화 부분에서 생각을 해봤는데, TicketOffice를 의인화해보면 충분히 티켓을 자율적으로 팔 수 있지 않을까요?
TicketSeller 라는 객체 자체가 저에게는 조금 어색하네요.