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

+ Recent posts