Create default entities - ckyeon #13
Conversation
ckyeon
commented
Aug 18, 2023
ckyeon
commented
- Create default entities #12
|
|
||
| @Getter | ||
| @EntityListeners(AuditingEntityListener.class) | ||
| @MappedSuperclass |
There was a problem hiding this comment.
ex) MappedSuperclass가 어느 용도의 어노테이션인가요?
| protected User() { | ||
| } | ||
|
|
||
| public User(String providerId, OAuth2Provider provider, String email) { | ||
| this(null, providerId, provider, email, Role.ROLE_USER); | ||
| this(null, providerId, provider, email, null, null, null, Role.ROLE_USER, false, false); |
There was a problem hiding this comment.
이 경우와 같이 constructor chaining을 사용하면 제공되지 않은 파라미터를 일관적으로 초기화 할 수 있고 코드의 중복을 줄여 유지보수가 편리해 진다고 들었습니다
그렇다면 Tag나 Relation 과 같이 비교적으로 프로퍼티가 적은 경우에는 굳이 사용할 필요가 없나용?
아니면 전체적인 일관성과 나중의 확장성(?)을 대비해서 그냥 다 쓰는게 좋을지 궁금합니다👍🏻
There was a problem hiding this comment.
이 경우와 같이 constructor chaining을 사용하면 제공되지 않은 파라미터를 일관적으로 초기화 할 수 있고 코드의 중복을 줄여 유지보수가 편리해 진다고 들었습니다 그렇다면 Tag나 Relation 과 같이 비교적으로 프로퍼티가 적은 경우에는 굳이 사용할 필요가 없나용? 아니면 전체적인 일관성과 나중의 확장성(?)을 대비해서 그냥 다 쓰는게 좋을지 궁금합니다👍🏻
프로퍼티의 갯수 보다는 default value가 필요하지 않은 경우에 사용하지 않아도 괜찮을 것 같습니다!
현재 기본 생성자를 숨겨둔 이유는 일관성, 중복 제거 등도 있지만 개발자의 휴먼 에러를 방지하기 위해서도 있습니다.
ex) Role의 기본값을 ROLE_USER로 해야하는데 이를 public으로 노출시키면 개발자의 실수로 'ROLE_ADMIN'을 지정할 가능성이 생김.
There was a problem hiding this comment.
constructor chaining의 추가적인 장/단점은 아래에서 확인해보시면 좋을 것 같습니다!
There was a problem hiding this comment.
오홍 답변 감사합니다
또, 기본값을 지정하는 코드가 Service 등에 흩어져 있는 것이 아니라 엔티티 하나로 응집되는 장점도 있을 것 같습니다~
