캡슐화 예제 질문드립니다

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

캡슐화 예제 질문드립니다

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