builder 패턴을 사용해야 하는 이유가 뭘까요???

Question

요즘 스프링 시큐리티 공부하면서 이것저것 찾아보다가 최근에는 builder 패턴이란걸 사용한다는걸 알게 되었습니다.(최근이 아니라 꽤 오래된...)인터넷에 builder 패턴 사용 이유 검색하면 관련 블로그가 수백개는 쏟아져 나오는데뭐 필요한 데이터만 설정할 수 있다...가독성을 높일 수 있다...코드에 유연성을 줄 수 있다...불편성을 확보할 수 있다...등등 정말 많은 이유가 있는데그냥 이렇게 setter로 넣으면 되는거 아닌가요???MemberDTO memberEntity &#61; new MemberDTO(); memberEntity.setId(email); memberEntity.setName(userName); memberEntity.setPw(passWord); memberEntity.setRole(MemberRole.ROLE_USER.toString()); memberEntity.setProvider(provider); memberEntity.setProvider_id(providerId);이걸 굳이 이렇게 바꿔서 사용하는걸 권장 하는 이유는 왜 일까요???memberEntity &#61; MemberDTO.builder() .id(email) .name(userName) .pw(passWord) .role(role) .provider(provider) .provider_id(providerId) .build();가장 중요한게 저 불변성 이라는 이유일것 같은데그러면 DTO (명칭이 잘못됫다면 VO) 에 setter 메서드가 없어야 하는게 맞지 않은지....가독성이 이유라면 그건 개발자의 취향 문제이기 때문에 따로 뭐라 할 말은 없을것 같고builder 패턴을 왜 써야하는 걸까요???코드량 때문이라면 어차피 Lombok 사용하면 setter를 일일이 써줘야 할 필요도 없는데 말입니다.&#x1f914;&#x1f914;&#x1f914;

76진 · Answer

저는 가장 큰 이유는 두가지라고 생각해요.하나는 가독성이고요. (경험적 선호)다른 하나는 개발자의 실수를 미리 막을 수 있게 도와줍니다. 게터 세터 오래전부터 사용해 온 개발자들이 의미없이 반복적인 사용에 불편함을 느꼈고, 빌더 패턴을 적용하면서 코드가 더 쉽게 이해되는, 가독성이 높아지는 걸 경험하고는 빌더 패턴을 선호하게 됐다고 생각합니다.또, 빌더 패턴은 생성자에서 필수값 지정이 가능합니다. Setter 는 필수값 지정이 불가능하여 다른 개발자들이 필수값을 넣지 않는 실수를 할 수 있지만, 빌더 패턴을 사용하여 특정 변수들만 필수적으로 생성자에서 받는 게 가능하기에, 개발자의 실수를 줄여주는 장점도 있습니다.

Clickin · Answer

setter를 언어 차원에서 만들지 말았어야 한다는건 좀 너무 나간 이야기고빌더 패턴을 통해 불변성을 적절히 부여해주면 GC가 사용이 끝난 객체를 빠르게 판단할 수 있다는 큰 장점이 있습니다.setter가 열려있다면 한번 만든 객체를 다시 수정할 수 있으니 가비지 컬렉터 입장에서는 객체의 각 필드를 계속 추적해야합니다.반면 빌더 패턴은 생성자를 기반으로 동작하고 setter를 배제하기 때문에 불변성을 부여하기 쉽죠. 불변인 객체라면 객체의 레퍼런스 포인터 갯수만 카운팅하고 0으로 떨어지면 메모리 할당을 해제하면 됩니다.

카카오콘 · Answer

지금은 &#64;Builder를 왜 쓰는가? 보다는 &#64;Setter를 왜 지양해야 하는가? 를 찾아보시면 좋을 것 같습니다.

yeori · Answer

원래 Builder 패턴이 고안된 배경은 이렇습니다.어떤 객체를 만들어야 하는데,내부에서는 다른 객체들도 함께 만들어야 함입력된 값에 따라서 내부에서 생성되는 객체 종류가 다를 수 있음입력된 값끼리 의존관계가 있어서 validation이 필요함생성 시간이 오래 걸리면 프록시 객체로 대체해서 가라로 빨리 생성하기이러한 구체적인 생성 과정을 외부에 노출시키고 싶지 않음(왜냐하면 나중에 바뀔 수도 있으니까)..등등 스프링이나 jpa같은게 나오기 전부터 생성 패턴의 한 종류로 존재해 왔습니다.객체를 만드는 과정이 복잡해서 사용하는 쪽이 실수할 여지가 많거나, 몇가지 입력값에 따라서 나머지 값들의 기본값이 거의 정해지거나, 동시에 사용하는 쪽 입맛에 맞게 커스텀하기 편한 인터페이스를 제공한다,뭐 요런 목적인데... 이게 JPA 쪽에서는 setter를 대체할 기법으로 널리 사용되는 모양입니다.님이 가져온 그 예제만 놓고 보면 빌더패턴을 강제해서 얻는 이득이 별로 없기는 합니다만...만일 패스워드 지정하는 코드 한줄을 빼먹었다면?패스워드 검증 로직을 일원화해야 한다면?이메일에 골뱅이(@)가 빠진 경우가 생긴다면?ROLE 부여 정책이 바뀌어서 과거의 ROLE을 커스터마이징 해야 한다면?setter로 값을 넣은 후에 부가적인 코드를 setter들 다음 어딘가에 넣을겁니다.이렇게 해서 [setter1, setter2, .. validation] 과 같이 코드가 전개되겠죠.그러던 어느날 정신줄 놓고 validation 호출을 빼먹으면?이상한 값이 디비로 들어갈테고, 이게 먼 훗날 또다른 오작동을 촉발하고, 그 오작동을 바로잡기 위해서 다른 누군가가 디비에서 꺼내온 후에 값을 보정하는 코드를 넣고...이런 식으로 코드가 너덜너덜해지는 일이 비일비재하죠.위에서 말했듯이 지금 내가 만드는 객체는 딱히 복잡하지도 않고 복잡한 조립 과정도 없는데 빌더패턴을 써야 하나?문제의식은 맞습니다.교조적으로 "빌더패턴 꼭 써야 해! 안쓰면 큰일나!" 생각하는 것보다는 낫다고 생각하고,다만 위의 예제만 놓고 보면 빌더패턴을 쓰는게 대단히 불합리하지도 않다는 겁니다.그리고 세상에는 나한테 꼭 필요하지 않지만 어지간하면 따르는 규칙들이 많습니다.정의의 문제도 아니고 누가 큰 불이익을 당하는 일이 아니면 걍 남들 하는대로 따라가는게 좋죠.영화 타짜에서 아귀 선생님도 말했어요.아이고~ ㅅㅍ 하고 싶은것만 하고 살 수 있나!

ppppqqqq · Answer

그러면 DTO (명칭이 잘못됫다면 VO) 에 setter 메서드가 없어야 하는게 맞지 않은지..네 dto에는 setter가 없어야 합니다

NPE · Answer

대개 적절한 예시가객체 생성시생성자의 인자가 많을때일부 필드를 선별적으로 넣는 경우가 생길때입니다.그리고 이와 상관없이 객체 생성은 불변성을 유지 하는 Value Object를 권장합니다.의도치 않은 변경은 상태를 예측하기 어려워요.

장독깨기 · Answer

글쎄요, 이런들 저런들 단순 데이터 객체에단순히 데이터 셋 하는 것에 무슨 장단점이 있겠습니까. 별 중요한 것도 아니고 그냥 끌리는데로 하면 될 일 입니다.

カワウソ · Answer

저는 provider_id 가 더 신경이 쓰이네요. 본 글이랑은 상관이 없으나...

builder 패턴을 사용해야 하는 이유가 뭘까요???

8개의 답변

Q&A 목록