Open kmw2378 opened 7 months ago
Ticket을 책에서 제시한대로 잘 의인화하신것 같습니다!
다만 어디까지나 코드를 작성하는 사람의 취향 문제라고 생각이듭니다만 저는 Ticket이 하나의 래퍼 클래스라는 생각이 듭니다.
그렇기에 가격을 가져오는 getFee
라는 메소드만 있어도 문제가 없다고 생각이 듭니다. 예제 코드에서 제시해주신 할인정책이 추가된다 하더라도 getFee
메소드 안에서 처리해도 충분하다는 생각이듭니다. 외부에서 바라본다면 Ticket
의 상태(가격)를 알지 못한채 Ticket
객체가 주는 가격 데이터만 알게 되니까요.
또한 작성해주신 purchasable(final Long money)
는 Audience
객체가 가지고 있는게 옳다고 생각합니다.
결국 Audience
가 가지고 있는 금액을 바탕으로 purchasable
메소드의 결과가 나오니까요.
그리고 이를 "객체지향의 사실과 오해"에서 나오는 말을 인용해서 표현하자면 다음과 같이 표현할수 있을듯 합니다.
행위(
purchasable
메소드)는 상태(Audience
가 가지고 있는 금액)에 영향을 받고 상태(Audience
가 가지고 있는 금액)는 행위(purchasable
메소드)에 의해 변경된다.
맨 처음에도 언급하였지만 어디까지나 저의 개인적인 생각일뿐입니다!
제 생각은 조금 다릅니다 말씀하신 purchase 메서드의 기능은 원래 있던 getFee + purchasable 이라고 생각해요!
hold 메서드에서 반환값으로 fee를 받기 때문에, Bag의 티켓 가격 확인 역할은 변하지 않았다고 생각해요
새로 만드신 purchasable 기능은 너무 좋다고 생각해요!
저도 비슷한 생각을 했었는데 ticket에 두는게 괜찮겠다는 생각입니다
sami님 의견을 보니, Audience 혹은 Bag에 두는게 더 좋겠군요ㅎㅎ,,
생각할 거리 주셔서 감사합니다~~ :clap: :partying_face:
현재
Ticket
클래스는fee
필드와 getter 메서드 외 별도의 역할이 없습니다. 만약 이를 의인화한다면 어떤 역할을 부여해야 할까요??현재 Ticket.java
저는
Bag
이Ticket
의 가격을 가져오는게 어색하다 생각했습니다. (객체 상태를 외부에서 판단하므로) 그래서 아래와 같은 리펙토링은 어떨까 합니다!변경한 Ticket.java
이렇게 리펙토링 시
Bag
의 책임은 아래와 같이 줄어들거라 예상합니다!기존
Bag
의 역할변경된
Bag
의 역할제가 리펙토링하면서 고려하지 못한 부분이나 다른 리펙토링법이 있다면 댓글로 남겨주시면 감사하겠습니다!!