Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Step3 #355

Open
wants to merge 14 commits into
base: yumble
Choose a base branch
from
Open

Step3 #355

wants to merge 14 commits into from

Conversation

yumble
Copy link

@yumble yumble commented Dec 9, 2023

DB연계를 생각하면서 하다보니 생각보다 많이 막힌 것 같아요ㅜㅜ

  • SessionType을 쿼리로 가져오려니 코드가 깔끔하다고 생각이 들지않아 리팩터링이 필요할 것 같아 리뷰어님 생각을 여쭤봅니다.. 제가 생각했던 방안은 3가지 정도였습니다.

      1. SessionType을 Free, Paid 타입 각각을 테이블에 저장하기
      • 이번에 구현한 방법입니다. JdbcSessionRepository에서 조인해서 가져오고 있으며, SessionType.determineSessionTypeByDB로 가져오고있습니다..
      1. SessionType을 하나의 테이블로 구성하기
      • 이렇게 구현하면, Free, Paid 타입을 어떻게 구분할지 애매해서 1번을 선택했습니다.
      1. SessionType 클래스를 없애고, Session 클래스에 maxStudents, sessionFee를 넣는 방식
  • 세션의 필드였던 List students를 session과 nsUser간의 다대다 관계라고 생각해서 student라는 클래스로 분리를 진행했습니다.

    • 관련해서 Session에서 현재 수용인원을 검사하는 로직을 students 클래스에게 위임하는 방식으로 변경했습니다.

@shared-moon
Copy link

a,b가 어떤 차이가 있는걸까요 ?
a는 테이블에 Free, Paid 라는 문자열을 저장하는건가 하고 이해했는데, 구현하신걸 보면 별도의 도메인으로 뺀 것 같아서, b로 구현을 하신 것 같아서요..!

말씀하신 방법들 다 방안이 될 수 있다고 생각해요. 하지만 c의 경우는 SessionType 별 분기되는 로직이 있기때문에 타입을 특정할 수 있는 정보는 있어야 할 것 같구요. 오히려 maxStudents나 sessionFee를 sessionsType이 책임지지 않게 하는게 맞을 것 같아요 예를 들면 A 강의와 B 강의 둘 다 유료강의인데 서로 다른 가격과 수강인원을 가지고 있다고 하면 sessionType에 묶이면 표현이 안 될 것 같아요..!

@yumble
Copy link
Author

yumble commented Dec 10, 2023

a번의 방법은 DB상에서 테이블을 Free table, Paid table로 분기를 했다는 걸 의미했던거고,
b번의 방법은 DB상에서 테이블을 SessionType table 하나로 두고, free이면 sessionType만 저장하고, paid이면 maxStudents, sessionFee의 정보까지 담아서 저장한다는 의미였어요,,

오히려 maxStudents나 sessionFee를 sessionsType이 책임지지 않게 하는게 맞을 것 같아요 예를 들면 A 강의와 B 강의 둘 다 유료강의인데 서로 다른 가격과 수강인원을 가지고 있다고 하면 sessionType에 묶이면 표현이 안 될 것 같아요..!
=> 이부분은 유료/무료를 구분하는 SessionType과 // maxStudents, sessionFee를 다른 곳으로 분기하는게 좋겠다라고 이해하면 될까요..?

Copy link

@shared-moon shared-moon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

현준님 안녕하세요!
몸살이 나서 피드백이 늦었네요 죄송합니다..!

3단계 미션 잘 진행 해 주셨네요 :)
코멘트를 좀 남겨 두었는데요, 확인 후 리뷰 재요청 부탁드려요!
고생 많으셨습니다 :)

@@ -1,13 +1,14 @@
package nextstep.courses.domain;

public class PaidSession extends SessionType{
public class PaidSession implements SessionType{

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

아 세션타입을 구현한게 세션이었군요 ?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DB 맵핑을 더 직관적으로 표현한다면, SessionType을 enum으로 만들고 DB에 업데이트 하는 정보를 enum을 넣으면 어떨까 싶네요! @Enumerated 를 String 타입으로 하는 것 처럼요!

}

public boolean isEnrollmentPossible(Integer sessionFee) {
public boolean isEnrollmentPossible(SessionStudents students, Integer sessionFee) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

저는 요 부분이 추상화가 되는게 맞지 않나 생각합니다..!

}

public boolean isEnrollmentPossible(Integer sessionFee) {
public boolean isEnrollmentPossible(SessionStudents students, Integer sessionFee) {

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

그리고 요거 enroll할때 내부에서 유효성검사를 하는식으로 해야되지 않을까요 ? 지금은 외부에서 판단하도록 되어있는 것 같아서요!

}

public boolean isWithinCapacity(SessionType sessionType) {
return sessionType.isWithinCapacity(students.size());

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sessionType을 가져와서 검증하는게 아니라 sessionStudents가 현재 수강인원을 제공해주는게 더 자연스럽지 않을까요 ?

return new PaidSession(isPaid, maxStudents, sessionFee);
static SessionType determineSessionTypeByDB(Long freeSessionTypeId, Long paidSessionTypeId, Integer maxStudents, Integer sessionFee) {
if (freeSessionTypeId == null) {
return new PaidSession(paidSessionTypeId, maxStudents, sessionFee);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SessionType의 구현체들이라 Type을 명시해주던가 다른 이름을 주는게 좋을 것 같아요
개인적으로는 EnrollmentStrategy 같은걸로 만들면 되지 않을까 싶네요..!

그리고 얘는 validateEnrollment 정도만 추상화를 하고, 내부에서 뭘 하는지는 각각의 구현체에 맡기고, 이 데이터들을 필드로 가지고 있는게 아니라 검증 할 때 파라미터로 받으면 되지 않을까요 ?

지금 밑에 있는 두개 메서드는 Free일때는 사실 아예 없어도 될 것 처럼 보여서요!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants