lect

답변 감사드립니다 많은 도움이 되었습니다
좋은 강의도 감사합니다^^

캡슐화 예제 질문드립니다

캡슐화 예제 중에&nbsp;
&nbsp;
if(mem.getVerificationEmailStatus() != 2) {
&nbsp; &nbsp; return AuthResult.NO_EMAIL_VERIFIED;
}
&nbsp;
위의 코드를 아래와 같이 바꾸는 예제가 있습니다
&nbsp;
if(!mem.isEmailVerified()) {
&nbsp; &nbsp; return AuthResult.NO_EMAIL_VERIFIED;
}
&nbsp;
vo와 jpa의 entity 같은 경우 한번 값이 세팅이 되면&nbsp; setter가 없기때문에 그 객체의 값이 변하는 경우가 없다고 알고 있습니다 (맞는 개념인지 확실히 모르겠습니다)
&nbsp;
그런데 vo, entity 를 쓰지 않고 단순 setter, getter 로 구성된 dto 를 이용하여 모든 레이어에서 사용하는 그런 형태의 개발환경에서
&nbsp;
dto 에 isEmailVerified() 와 같은 메소드를 만들어서 캡슐화를 하는 것도 괜찮은 것인지 질문을 드렸습니다
&nbsp;
이런 생각이 든 이유는 vo, entity 같은 경우는 값이 변하지 않지만
&nbsp;
dto 같은 경우 아래와 같이 검증을 한번 한 후에 setter 를 이용해서 값을 바꿔버릴 수가 있고 다시 mem.isEmailVerified() 를 호출했을때
&nbsp;
결과에 대한 일관성이 깨질수도(?) 있다는 느낌을 받았습니다 물론 이것은 당연한 결과이고 값을 바꾸지 않으면 될 문제인 것 같기도 합니다
&nbsp;
하지만 그럴 소지가 있는 환경 혹은 클래스에도 이런 것들을 적용해도 무방한 것인가 라는 생각이 들었고 질문을 드리게 되었습니다
&nbsp;
if(!mem.isEmailVerified()) {&nbsp; //return true
&nbsp; &nbsp; return AuthResult.NO_EMAIL_VERIFIED;
}
&nbsp;
mem.setVerificationEmailStatus(3);
&nbsp;
if(!mem.isEmailVerified()) {&nbsp; //return false
&nbsp; &nbsp; return AuthResult.NO_EMAIL_VERIFIED;
}
&nbsp;
이런 리팩토링 관련 강의를 듣다보면 이런것들을 적용할 수 있는 환경(jpa 를 사용하는 프로젝트) 혹은 클래스(setter 가 없는 불변성 클래스) 여야만 하는가?
라는 질문이 머리속에 있었는데
최범균님께서 달아주신 답변을 보면 dto, vo, entity, 불변, jpa , setter/getter 여부 등과 관계없이 사용해도 상관이 없으며
오히려 사용하면 단순 dto (수업 중 구조체에 가깝다고 말씀하신) 에서 진정한 객체에 되려 가깝게 되는 것이다 라는 의미로 해석되는데 맞는 것인지 궁금합니다
&nbsp;
처음 질문 드린 내용과 중복된 내용이지만 질문을 자세하게 말씀드리지 못한 것 같아 다시 질문을 드리게 되었습니다
이미 좋은 답변을 해주셨지만 번거로우시더라도 한번 더 말씀해주시면 정말 많은 도움이 될 것 같습니다
&nbsp;
좋은 강의 감사드립니다

lect

Posts