Spring
- Getter, Setter의 적절한 사용
Controller를 드나드는 다양한 DTO들.. 어떤 DTO는 getter만 있기도 하고, setter만 있기도 하고, 둘 다 있기도 하고 생성자가 있기도 하다. 오늘 코드 리뷰 중 팀원 분께서 request dto는 setter가 필수라는 말씀을 해주셔서 이 이유에 대해 알아보려 한다.
request dto를 받을 때는 클라이언트에서 json 데이터가 넘어온다 가정을 하고 @RestController를 많이 사용한다.
이때 SAbstractJackson2HttpMessageConverter 에서 Json -> dto 객체로 변환이 일어나는데. 여기서 json의 key-value 값을 객체의 field-value 값으로 전환시켜주기 위해서는. 필드값을 세팅하기 위해 setter가 필요하다.
response dto를 내보낼 때에는 dto 객체를 json body로 바꾸어줘야 한다.
이제는 반대로 dto의 field-value 값을 key-value 값에 넣어주어야 하니, field-value 값을 빼낼 getter가 필요한 것이다.
dto <-> json body 의 변환을 위해 getter, setter 가 필요한 이유는 납득이 된다.
그렇다면 모든 dto, entity 등등에 getter, setter, allarg, noarg 다 하면 손해볼 게 없는 것 아닌가?
둘 다 남발하면 안된다!!
getter를 남발하면 안되는 이유.
필드를 private로 잘 설정해 놓고 모든 필드값을 getter로 꺼내올 수 있다면 캡슐화의 의미가 퇴색된다.
setter를 남발하면 안되는 이유.
1. setter로 인해 모든 곳에서 객체 값의 변경이 가능할 텐데, 그러면 객체 값을 변경해주는 메소드의 의미가 퇴색된다. + 의도치 않게 값이 변경될 가능성이 있기 때문에 지양해야 한다.
2. setter를 꼭 필요한 필드에만 만들어 놓으면 값을 변경하는 케이스가 희귀하다는 의미이므로 의도 파악이 명확해진다.
알고리즘
- 프로그래머스 : 방금그곡(Level 2, 문자열)
느낀 점
.
'TIL' 카테고리의 다른 글
[23.11.29] (0) | 2023.11.29 |
---|---|
[23.11.28] (0) | 2023.11.28 |
[23.11.21] (0) | 2023.11.21 |
[23.11.20] (0) | 2023.11.20 |
[23.11.17] (0) | 2023.11.17 |