5장 책일 할당하기

[lee-ji-hoon]

No description provided.

[lee-ji-hoon]

올바른 도메인이란 존재하지 않는다. p138

• 2장의 도메인 모델과 다른데 둘 중에 정답은 없었다.
• 둘 모두 올바른 구현을 이끌어낼 수만 있다면 정답은 둘 다 된다.
• 가만 생각해보면 둘 다 가능하지만 사람마다 개인 취향은 존재할 것이도 좀 더 선호하는 부류가 분명히 존재할 것이다.

개인 취향으로는 2장에서 다뤘던 할인 정책도 따로 나누는 것을 더 선호하는데 다들 어떤지 궁금함

• 지금 현재는 영화관이지만 영화만 상영한다는 보장은 없음
  • 예를들어 롤 리그를 상영한다던지 하는 경우에 그럼 비율할인리그 + 금액할인리그 이렇게 두 개가 새로 만들어지게 된다.
  • 그것보다는 그냥 리그 클래스를 하나 만들고 거기에 할인 정책을 넣는게 좀 더 좋아 보인다.
• 이렇게 새로운 비즈니스 모델이 추가되는 경우는 되게 잦다고 생각해서 가능한 최대한 세분화 시키는게 좀 더 취향

[audxo112]

개인 취향으로는 2장에서 다뤘던 할인 정책도 따로 나누는 것을 더 선호하는데 다들 어떤지 궁금함

• 지금 현재는 영화관이지만 영화만 상영한다는 보장은 없음

  • 예를들어 롤 리그를 상영한다던지 하는 경우에 그럼 비율할인리그 + 금액할인리그 이렇게 두 개가 새로 만들어지게 된다.
  • 그것보다는 그냥 리그 클래스를 하나 만들고 거기에 할인 정책을 넣는게 좀 더 좋아 보인다.

• 이렇게 새로운 비즈니스 모델이 추가되는 경우는 되게 잦다고 생각해서 가능한 최대한 세분화 시키는게 좀 더 취향

할인 정책이
개인에 따른 생일, 쿠폰, 컨텐츠 등에 따라 너무 다양하게 들어 올 수 있는 구조여서 파라미터가 너무 다양하게 들어올 수 있는게 문제라 생각
결국 다시 if 문이 생겨서 목적에 따른 method 가 만들어질 것 같은데

해결하기 위해서 json 같은 데이터를 주고
내부에서 알아서 파싱해서 파라미터를 넘기는 방식을 생각해봤음
(Retrofit 에서 MoshiFactory 가 알아서 json 을 class 로 만들어서 파라미터로 넘겨주는 것과 같음)

[audxo112]

이번 장에서는 클래스 응집도를 판단하는 기준을 명확히한 단원이였음

• 변경의 이유는 하나여야한다
  • 아직 이 부분은 와닿지 않음
• 객체가 생성될 때 초기화 되지 않는 변수가 있다
  • kotlin 의 data class 를 사용하면서 자연스럽게 응집도가 높은 클래스를 만들게 된 거 같다는 생각
• 객체가 type에 따라 다른 메서드를 사용한다