2021.07.16 기록장

TIL 2021. 7. 15. 23:28

토비의 스프링

335p. 비즈니스적 의미의 위치

예제로 user는 회원가입 시에 Basic 등급을 갖는다.

이 부분은 어디서 초기화해주는 것이 좋을까?

처음 든 생각은 생성자에서 초기화해주는 것이 좋다는 생각이었다. 생성을 하면서 기존 정책을 반영하는 것이니까.

책에서 소개한 방법 몇 가지를 보면

1. 필드에서 초기화하는 부분. 하지만 처음 가입할 때를 제외하면 무의미한 정보이기에 이 로직을 클래스에서 직접 초기화하는 것은 문제가 있다고 판단하고 있다.

2. UserDao add시에 초기화. 이는 DB에서 읽고 쓰기만 해야 하는 class에서 비즈니스적인 의미를 지닌 정보를 설정하는 것은 옳지 않다.

3. UserService에서 넣기. UserService에도 add 메서드를 만들어서 사용자가 등록될 때 적용할 만한 비즈니스 로직을 담당하게 하면 될 것이다. --> 토비님이 추천한 방법.

이렇게 되면 나중에 특이한 경우로 생성 초기에 높은 등급을 가진 유저를 만들 수 있다. --> 변경에 대응 가능

처음 든 생각을 다시 생각해 보니 생성자에서 파라미터로 받지 않고 초기화를 하면 특별한 경우(어드민 계정. 생성 등급이 골드)를 만들 수 없다. 이렇게 되면 나중에 User class를 변경하게 될 것이다. or 생성자 파라미터로 애초에 받아도 될 듯

342p. 예외 상황, 예외 발생

User의 등급을 업그레이드하는 메서드에서 마지막 등급이 업그레이드를 하면 예외가 발생하는 로직이다.

과거에 예외에 관해(https://gisungcu.tistory.com/242) 생각한 적이 있다.

대입해서 생각해 보면 업그레이드가 가능하지 검증하는 코드가 먼저 실행되어야 한다. 책에서는 service에서 정의되어있는데(canUpgrade()) 이 부분이 먼저 실행되어야 한다.

근데 UserService에서만 User를 사용하는 것이 아니다. 이는 항상 위의 canUpgrade() 메서드가 먼저 실행된다고 볼 수 없는 이유이다. 그렇기에 upradeLevel() 메서드에서는 스스로 예외상황에 대한 검증 기능을 가지고 있는 것이 안전하다.

.now() .now()