-
질문답변: DTO를 만들 때 왜 HTTP Method별로 따로 만들어야 하나요?기타 2022. 10. 22. 12:46
질문
(생략)...
굳이 왜 두개의 클래스로 구분해서 만들까라는 의문이 들었습니다. 왜냐하면 클라이언트에서 받는 요청은 어차피 같은 형식의 데이터로 올것이고, 그안에 정의되어있는 body값, json 형태의 key와 value는 post던 patch던 이미 사전에 정의된 같은 key에 대한 value만 들어올것이기 때문입니다.
예를 들어, 현재 member에서는 이미 요청으로 들어올 값들이 새로운 멤버 생성이던(post) 기존 멤버의 정보를 변경하던(patch) 요청으로 들어오는 message의 body값은 memberId, email, name, phone로 한정되어 있습니다. 따라서 각각의 post dto, patch dto가 아닌 하나의 member dto 객체로 받아온다면 굳이 여러개의 dto를 만들 필요가 없다고 생각합니다.
...(생략)부트캠프 수강생 커뮤니티에 이런 질문이 올라와서 답변을 달았습니다. 저도 처음 DTO를 접했을 때 생각해보았던 부분이어서요.
답변을 달아놓고 보니 포스팅으로도 옮기면 좋을 것 같아서 복붙해봅니다(포스팅 날로 먹겠다는 말).답변 전문
안녕하세요 😀
좋은 고민이네요, 저도 궁금해서 찾아보고 고민해봤던 부분이라 몇 자 남겨볼게요.
현재는 post와 patch의 파라미터가 같지만 만약 앞으로 달라진다면 어떨까요? 같은 객체를 파라미터로 사용한다고 가정하고 생기게 될 문제들을 이야기 해볼게요.post의 파라미터가 추가될 필요가 있다면 파라미터 객체에 필드를 추가해야겠죠. 그러면 같은 객체로 patch를 시도할 때에는 의미를 알 수 없는 null 필드들이 보일 거에요. 그러면 patch 기능을 담당하고 있는 프로그래머는 이 필드들을 보고 '뭐지? 언제 생겼지? 필요 없는 값인데 추가가 되어있네? 뭔가 테스트해보려고 추가한 건가?' 라고 생각하겠죠. 그래서 만약에 필요 없다 생각하고 추가되었던 필드를 지워버린다면? 이젠 변경했던 post에서 오류가 나겠죠. 혹은 patch를 담당한 프로그래머가 사려 깊은 사람이라서 '다른 쪽에서 오류가 날 수도 있으니까...'라고 생각해서 지우지 않을 수도 있을 텐데요...
진짜로 필요 없는 값이어도 문제입니다. '이 파라미터 객체가 프로그램 어딘가에 공유되고 있을 수 있다'는 전제를 깔게 되면, 진짜 쓸모없다고 판단되는 필드도 어디선가는 쓰고 있을 수 있기 때문에 삭제할 수가 없게 되어요. 그러면 프로그램은 쓸모없는 코드들로 더러워지고, 점차 수정하기 어렵게 되겠죠.
진짜로 똑같은 값만 사용해도 문제입니다. 지금은 파라미터 개수가 두 개니까 금방 확인이 되는 거죠. 만약에 파라미터가 20개쯤 있는데 post와 patch는 그 중에서 정확히 동일한 12개의 파라미터만을 사용합니다. 아니, 정확히 동일하게 사용해야만 해요. 그러면 '정확히 동일한 파라미터 12개를 사용하고 있는지'는 누가 확인하죠?... 프로그래머가 하겠죠. 그리고 인간은 곧잘 실수를 하고요.
혼자서 모든 소스코드를 진짜로 잘 파악하고 있어도 문제입니다. 내가 아닌 다른 사람이 코드를 수정하면요? 본인이 '여전히 전체를 잘 파악하고 있는지 확인하기 위해서' 수정된 소스코드를 다시 확인해야 합니다. 매우 비효율적이죠. 가능할 것 같지도 않고요(그런게 가능하면 버전관리가 나오질 않았겠죠). 그렇다고 혼자 일할 테니까 소스코드를 수정하는 다른 사람들을 다 해고해달라고 할 수도 없을 거고요.
몇 가지 이유가 더 있을 것 같은데... 다른 이유에 대해서는 스스로 생각해보셔도 좋을 것 같고요😅... 공통된 요점은 프로그램의 확장성을 저해한다는 것이에요.
물론... '그래도 지금은 필요없잖아?! 이 간단한 예제에서까지 굳이 나눌 필요가 있나?'라고 생각하실 수도 있어요.
하지만 파라미터가 요구 사항을 따라 변경되는 일은 미리 대응해둬야 할 만큼 몹시 빈번히 일어나는 일이고, 원칙(하나의 파라미터는 하나의 동작에만 대응한다)을 어김으로 인해서 일어나는 파급이 너무 커요.지키기 위해 고려해야 하는 것 <<<<<< 지키지 않았을 때 고려해야 하는 것
인 거죠.
또 적용하기에도 쉬운 원칙이기 때문에 연습 차원에서 습관을 들여두시면 미래의 삽질을 많이 줄이실 수 있을 거에요.행동의 가성비를 따지는 거죠😁
'기타' 카테고리의 다른 글
우아한 테크캠프 6기 코딩테스트 후기 및 팁 (5) 2023.05.09 갑자기 프로젝트 바람이 돌아서 (3) 2022.12.16 openssl로 crt/pem 인증서를 p12로 변환하고 tomcat에 설치하기 (0) 2022.10.24 어제는 프로젝트 발표일이었다. 코드스테이츠 백엔드 부트캠프의. (2) 2022.10.13 대략적인 서버 구성 (0) 2022.08.25 간단한 사용법: Java/Selenium과 함께한 자동로그인(이라고 쓰고 삽질이라고 읽는 것) (0) 2022.08.05