빌더패턴으로 DTO 를 생성하는 이유가 궁금합니다.

Question

OrderDto orderDto &#61; OrderDto.builder() .uuid(uuid) .memo(&#34;문앞 보관 해주세요.&#34;) .orderDateTime(LocalDateTime.now()) .orderStatus(OrderStatus.OPENED) .memberDto( MemberDto.builder() .name(&#34;lee&#34;) .nickName(&#34;yeoooo&#34;) .address(&#34;숲 속&#34;) .build() ) 위 코드는 인터넷에서 검색한 DTO 생성하는 코드입니다. 언제부터인지 모르겠지만 DTO 생성시 빌더 패턴을 자주 사용하더라구요. 보통 빌더 패턴으로 DTO 를 생성하면불변성을 지킬 수 있고데이터 타입을 표현할 수 있고생성자가 복잡해지는걸 방지할 수 있고마지막으로 다른 코드와 낮은 결합도를 유지할 수 있다고 하는데요. 제가 보기엔 일반적인 getter, setter 이 있는 DTO 와 다를게 없어 보입니다.불변성을 지킬 수 있다고 하지만 개발자의 코드로 다른 데이터를 가진 DTO 로 변환시킬 수 있고데이터 타입을 표현하는건 get,set 메소드에서도 가능하고생성자가 복잡해질 필요 없이 빌더패턴에서 코딩하는 양 만큼 set 메소드를 나열하면 되고반복되는 빌더메소드, get 메소드가 다른 소스코드에 하드코딩 되어 있어 gettter, setter 하고 똑같은 높은 결합도가 되는 것 같거든요. 오히려 빌더 패턴때문에 반복되는 객체 생성 비용이 문제되고 코드 보기도 어려운것 같은데 DTO 생성시 빌더패턴을 사용하는 장점이 궁금합니다. 제가 잘못 생각하고 있거나 장점이 있으면 알려주시겠어요.DTO 빌더페턴 장점을 설명하는 글이 많습니다. 그런데 전부 비슷한 내용을 이야기 하고 있습니다. 장점이 아닌데도 장점으로 이야기 하는 내용이 잘못된것 같아 질문글 올렸습니다. 댓글 달아 주신 분들 내용 잘 이해 했구요. 제 생각을 정리합니다.빌더패턴으로 만들어진 DTO 불변성은 장점이 아닙니다. 코드를 복잡해지게 만드는 문제가 됩니다. 요구사항 구현을 위해 데이터는 변경할 수 밖에 없습니다. 이를 위해 불변성이 있는 DTO 의 데이터를 꺼내 새로운 DTO 를 만드는 이상한 코드가 반복됩니다. DTO 의 set 메소드 한번이면 끝날 문제를요.멀티쓰레드로 실행되는 WAS 에서 생길 수 있는 동기화 문제를 해결하기 위해 스프링 같은 프레임웍은 쓰레드로컬을 사용합니다. 쓰레드로컬 덕분에 비즈니스로직 실행에 필요한 DTO 는 동기화 문제를 신경 쓰지 않아도 됩니다. 불변성이 없어도 말이죠.동기화가 필요한 DTO 는 동기화 구문으로 해결해야 합니다. 불변성이 동기화 문제를 해결할 수 없습니다. 불변성으로 제공되는 읽기전용 데이터는 멀티쓰레드 코드에 복사되고 변경됩니다. 그렇기 때문에 불변성 DTO보단 동기화 구문으로 해결해야 합니다.DTO 불변성이 데이터를 안전하게 해준다고 믿으면 안됩니다. 우리는 코드를 만들고 있고 DTO 불변성은 언제든지 깨질 수 있습니다. 데이터를 안전하게 해주는건 불변성으로 위장한 정보은닉이 아닌 인스펙션입니다.DTO 의 생성자는 복잡할 필요가 없습니다. 복잡하다는 건 DTO 를 잘못 만든 것이지 이를 빌더패턴으로 해결하면 안됩니다. 그래도 불변성이 필요하면 빌더패턴을 사용하지 말고 정보은닉을 하세요. 디자인 패턴의 빌더패턴은 불변성을 보장하지 않습니다. 이를 위해 억지(?)를 부린 lombok 을 사용하고 있죠.데이터 품질은 사용시점에 결정됩니다. null 을 허용할수고 있고 키가 아닐수도 있습니다. 이메일같은 검증로직이 들어갈 수 있구요. DTO에서 데이터 품질을 보장하는 순간 다른 레이어(모델,뷰 등)와 역할이 모호해져 코드는 어려워 집니다. 중복되는 DTO는 덤이구요. 빌더패턴, 불변성과 관련이 없지만 DTO에 데이터 품질을 보장하는 장점이 있다 해서 적어봅니다.빌더패턴이 가독성 좋다고 하는건 익숙해서 그렇습니다. 어떤 컨벤션이던지 익숙해지면 보이고 편합니다. 하지만 생성자 체인 형태는 디버그 할 때 정말 불편합니다. 뭐 이건 디버그를 안하면 편할 수 도 있겠네요.우리는 요구사항을 잘 이해하고 쉽게 구현해야 합니다. 불변성이 있는 DTO 는 장점이 될 수 없고 불편함이 되고 쉬운 코드가 될 수 없는 문제가 됩니다. 불편함이 있지만 다른 장점이 있어 사용한다고 하는 건 맞지만 불편함이 장점이라 하는건 바보같아 보이네요. 이부분을 이야기 드리고 싶었습니다.

메로나한입만 · Answer

일단 저는 가독성이 좋아서 씁니다필드가 많은 경우에 생성자 길어지는것도 없어서 좋구요

siva6 · Answer

많은 생성자를 대체할 수 있는 장점이 있기는 한데요.질문 하신 분은 empty object를 만들고 set으로 초기화 하는 방법을 사용하시고 싶으신 것 같은데요.그 경우 저 패턴이 좋은 점은 build시에 객체의 필수 값이 세팅되었는지 확인하고 제한 할 수 있습니다.예제의 uuid가 필수인데, set방식으로 하면 uuid가 없더라도 객체를 생성할 수 있게 됩니다.그리고, 잘 사용되지는 않지만 객체 생성을 지연시킬 수 있습니다.

엡실론 · Answer

빌더 패턴을 쓸 때는 setter는 만들지 않습니다. setter를 쓸거면 빌더 패턴을 쓰는 의미가 없죠.

지붕뚫고높이차 · Answer

비냄세가조아--------------------------------MemberDto.builder().name("lee").nickName("yeoooo").address("숲 속").build();빌더 패턴으로 만들어진 코드와MemberDto m = new MemberDto();m.setName("lee");m.setNickName("yeoooo");m.setAddress("숲 속");setter 으로 만들어진 코드는 똑같은 라인수와 가독성도 비슷한 것 같은데 다른 문제가 있을까요?

allinux · Answer

1 번 항목은 뭔가 잘못알고 있는 듯 합니다.필드를 셋팅하고 build 호출시 객체가 만들어지기 때문에 불변성을 가진다는 것이고 set 을 통한 "수정"은 객체의 필드값을 변경하기 때문에 멀티쓰레드 환경등에서 문제가 될 수 있다는 겁니다.

ii!!ii!! · Answer

필드 값이 여러개일 경우 필요한 매개변수 갯수만큼 생성자를 만들게 될텐데, 이 때 매개변수의 조합만큼 많은 양의 생성자가 필요합니다.하지만 만약 기본 생성자와 setter로만 객체를 생성하겠다고 한다면 생성자의 수가 늘어나지는 않습니다.그러나 객체 하나를 생성하는데에 있어 메서드를 여러개 호출해야 하고, 그 사이에 객체의 일관성을 지킬 수 없게됩니다.또한 setter를 필수로 사용해야 하므로 불변성을 지킬 수 없게 됩니다.이 패턴은 자바빈즈 패턴이라고 합니다. 검색해보시면 좋을 것 같습니다.

지붕뚫고높이차 · Answer

빌더 패턴이 불변성이 아닌 이유를 적어봅니다. MemberDto dto = MemberDto.builder().name("lee").build();만들어진 dto 객체에 있는 name 은 수정할 수 없습니다. settter 가 없기 때문이죠.그래서 불변성이 있다고 이야기 하는데요.MemberDto dto = MemberDto.builder().name("lee").build();.. name 이 lee 가 아니고 lee2 가 되어야 하는 이유가 생김dto = MemberDto.builder().name("lee2").build();코드처럼 얼마든지 개발자의 코드로 dto 값을 변경할 수 있습니다. 빌더 패턴의 dto 가 불변성이 있는 것처럼 보이지만 변경 가능하지 않나요?

지붕뚫고높이차 · Answer

동기화 문제에 대해 답글로 적어봅니다. 잘못된 내용 있으면 알려주세요.MemberDto dto &#61; MemberDto.builder().name(&#34;lee&#34;).build();멀티쓰레드구문(dto); MemberDto dto &#61; new MemberDto();dto.setNmae(&#34;lee&#34;); 멀티쓰레드구문(dto); 빌더 패턴으로 만들어진 dto 는 불변성이 있기 때문에 문제되지 않지만 setter dto 도 멀티쓰레드 구문에서 setter 를 사용하지 않는다고 하면 문제가 없지 않나요? 물론 멀티쓰레드구문 에 lee 가 lee2 가 바뀌는 로직이 있을 수 있고 setter 를 사용하면 동기화 문제가 발생하는 건 맞습니다. 하지만 빌더 패턴을 사용하더라고 똑같지 않나요?lee 를 lee2 로 변경해야 하고 멀티쓰레드구문 안에서 dto &#61; MemberDto.builder().name(&#34;lee2&#34;).build(); 코드가 들어가야 하잖아요. 둘다 데이터 값을 변경하는 코드에 동기화 구문을 사용하면 문제는 안되구요. DTO 의 동기화 문제는 DTO 문제가 아닌 동기화 구문을 잘못 사용한 문제입니다. 빌더 패턴이나 setter 나 똑같은 동기화 문제를 가지고 있습니다.

오짱이에요 · Answer

결론부터 말하자면은...DTO 생성시에는 별로 쓸 이유가 없습니다...만...이건 DTO 생성 시 그렇다는것이고... 다른 경우에는 builder가 굉장히 유용한 경우가 있습니다...언제 builder가 유용합니까? -> 이건 널려있으니 찾아보면 되구요...왜 DTO 생성 시 에는 builder가 크게 필요하지 않습니까? -> 이건 위에꺼 찾아보면 따라올것이고..근데 본문은 setter랑 차이가 없는것 같다 -> setter는 construction pattern이 아닌데...둘이 어떻게 엮어서 물어보는건지...?

Ⓜ️Z계발자(ENFP) · Answer

쓸 이유 없음 ㅋ

빌더패턴으로 DTO 를 생성하는 이유가 궁금합니다.

10개의 답변

#gettter 목록