인프런 커뮤니티 질문&답변

작성자 없음

작성자 정보가 삭제된 글입니다.

실전! 코틀린과 스프링 부트로 도서관리 애플리케이션 개발하기 (Java 프로젝트 리팩토링)

13강. 도메인 계층을 Kotlin으로 변경하기 - UserLoanHistory.java, User.java

강사님 안녕하십니까 코틀린 var 선언에 대해서 질문이 있습니다.

작성

·

334

1

var 를 선언하게 되면 setter 를 사용한 것 처럼 외부에서도 클래스 내부 필드에 접근하게 되어 캡슐화가 되지 않아서 setter 를 막아주고 싶습니다. 만약 그렇게 하고싶다면 모든 필드에 private set 을 선언해야할 것 같은데 중복코드의 느낌도 있고, 코틀린의 간결함이랑 멀어진다는 생각이 들었습니다. 보통 실무에서는 도메인, jpa 엔티티를 분리하는 방법이 아닌 set 을 막으려면 어떻게 처리를 하는지 궁금합니다.

답변 2

1

유튜브 영상을 봤어가지고 질문 지우려했는데 벌써 답변을 주셨군요 감사합니다..! 역시 트레이드 오프를 잘 해야 하네요. 잘 선택해서 하겠습니다. 감사합니다!

0

최태현님의 프로필 이미지
최태현
지식공유자

안녕하세요 명구님! 정말 좋은 질문 감사드립니다! 😊

바로 이 내용이 다음 회차인 14강에서 나오는데요! 말씀해주신 것처럼 @Entity 클래스에서 setter를 막으려면 몇 가지 문법적인 요소를 사용해 번거로운 작업을 해주어야 합니다. 🥲

 

실무에서는 크게 2가지 접근 방식이 있는 것 같습니다.

  • 문법적으로 번거롭더라도 setter를 확실히 막아주자!

  • 그냥 setter를 열어는 두고 사용하지는 말자!

    • 코틀린의 문법적 간결함을 활용하지만, setter 를 사용할 수도 있다는 불안감(?)을 안고 가는 접근입니다.

    • 매우 개인적으로는 setter 가 열려 있어도 사용하지 않는 편이라 이 방법을 선호하고 있습니다 🙂

 

어떤 방법이건 정답은 없는 것 같습니다.

  • Kotlin ORM인 Exposed (https://github.com/JetBrains/Exposed) 를 JPA 대신 사용하는 것도 애매하고요!

  • 바이트 코드 조작 기술을 사용해 setter를 제거해주는 플러그인을 직접 만들기도 많~이 애매하죠..

 

결국 번거롭더라도 setter를 확실히 막거나, setter를 열어두고 쓰지 않거나 하는 방법으로 팀 간의 컨벤션을 잘 정해야 하는 것 같습니다.

답변이 도움이 되었으면 좋겠습니다. 감사합니다!! 🙏🙏

작성자 없음

작성자 정보가 삭제된 글입니다.

질문하기