팩터리 메소드와 response 객체 사용 이유가 궁금합니다!
안녕하세요
게시판 강의 보면서 정말 잘 배우고 있습니다!!
국비학원 프로젝트 하던 때를 생각해보면서 듣고 있는데, 그때는 엔티티에 생성자를 만들어서 서비스에서 그냥 썼는데 본 강의에서 팩토리 메소드 형태를 사용하는 이유가 궁금했습니다!! (기술적으로 더 진보한 형태인지요)
그리고 객체마다 response를 만들어서 commentResponse, ArticleLikeResponse 같은걸 만들어 api 반환에 사용하는데, entity랑 필드도 다르지 않은데 굳이 이렇게 일일이 response 객체를 각각 만들어서 코드를 짜야하는지 궁금합니다!!
Answer 2
0
88diaspora님, 안녕하세요!
잘 배워주고 계시다니 감사하네요!
국비학원 프로젝트 하던 때를 생각해보면서 듣고 있는데, 그때는 엔티티에 생성자를 만들어서 서비스에서 그냥 썼는데 본 강의에서 팩토리 메소드 형태를 사용하는 이유가 궁금했습니다!! (기술적으로 더 진보한 형태인지요)
동일한 클래스더라도 객체에 대한 생성 의도는 모두 다양할 수 있는데요, 생성자와 달리 팩토리 메소드는 네이밍으로 의도를 명확하게 드러낼 수 있습니다.
예를 들어, User 객체를 생성한다면, 관리자(User.admin()), 일반 사용자(User.normal()), 단순 변환(User.from(dto)), 에러 시에 디폴트 객체 응답(User.empty()) 등 팩토리 메소드를 활용하면 코드의 의도가 더욱 명확하게 드러나게 됩니다.
또, 매번 새로운 객체를 생성할 필요 없이 동일한 객체를 재사용해도 된다면, 팩토리 메소드에서 캐시된 객체를 반환하는 등 더욱 유연하게 활용할 수 있고요. (User.empty() 같은건 싱글톤 객체로 반환)
다른 이점으로는 하위 타입으로 반환해줄 수도 있습니다. 예를 들어, List는 인터페이스인데 List.of(“a”)는 실제 하위 타입으로 구현체를 만들어줍니다.
외에도, 팩토리 메소드와 생성자의 차이는 검색해 보시면 많은 자료를 찾아보실 수 있을 것 같네요!
그리고 객체마다 response를 만들어서 commentResponse, ArticleLikeResponse 같은걸 만들어 api 반환에 사용하는데, entity랑 필드도 다르지 않은데 굳이 이렇게 일일이 response 객체를 각각 만들어서 코드를 짜야하는지 궁금합니다!!
반드시 그럴 필요는 없지만, 내부적인 도메인 모델과 응답 모델을 별도로 관리하는게 유리한 상황이 많습니다.
클라이언트에게 불필요한 데이터까지 도메인 모델에 포함된 상황(보안, 데이터 크기, 전송 지연 등 문제)
클라이언트의 요구사항과 도메인 모델이 일치되지 않는 상황(여러 모델을 조합하거나 추가적인 가공이 필요할 수 있음)
위와 같은 상황들을 생각해 보시면 이해가 편할 것 같네요!
0
안녕하세요, 인프런 AI 인턴입니다. 88diaspora님.
질문해 주신 내용에 대해 차례대로 답변해 드리겠습니다.
팩토리 메소드 사용 이유
객체 생성 로직의 캡슐화: 팩토리 메소드 패턴은 객체 생성 로직을 캡슐화하여, 더 유연하고 안전한 객체 생성 방식을 제공합니다. 생성자를 직접 호출하는 대신 팩토리 메소드를 사용함으로써 객체의 생성 과정을 좀 더 명확하게 제어할 수 있습니다.
매개변수 타입 체크 및 유효성 검증: 팩토리 메소드는 객체 생성 시 입력되는 매개변수의 타입 체크나 유효성 검증을 수행하여 불필요한 에러를 사전에 방지할 수 있습니다.
코드의 가독성 및 유지보수성 향상: 팩토리 메소드를 사용하면, 객체 생성 코드가 명료해지고, 새로운 객체 생성 방식이 필요할 때 기존 코드를 변경하지 않고도 간단히 확장할 수 있습니다.
Response 객체를 따로 만드는 이유
레이어 분리: 서비스 레이어에서 사용할 엔티티와 API 응답으로 반환할 데이터는 분리하는 것이 좋습니다. 이는 SRP(단일 책임 원칙)를 따르며, 각 클래스가 하나의 책임만을 가지도록 설계함으로써 코드의 유지보수성과 확장성을 높입니다.
불필요한 데이터 노출 방지: 엔티티에는 데이터베이스와 관련된 민감한 정보나 내부 비즈니스 로직이 포함될 수 있는데, 이러한 정보를 외부에 노출하지 않기 위해 response 객체를 사용하여 필요한 데이터만을 반환합니다.
응답 형식의 일관성 유지: 특정 API의 응답 형식을 일관되게 유지할 수 있으며, 클라이언트에 필요한 형식으로 데이터를 조정할 수 있습니다.
관련하여 더 많은 정보를 원하신다면 아래 유사한 질문에 대한 답변들을 참고해 보세요:
- 27강(댓글 무한 depth - CUD API 구현 & 테스트 데이터 삽입 Comment Response 관련 질문)
- XxxResponse를 service 패키지에 두신 이유가 궁금합니다.
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
consumer에서 에러가 발생할 경우 데이터 유실 문의
0
38
2
게시글 테스트 데이터 삽입
0
43
2
정렬, 필터, 검색 등의 조건이 붙을 경우 최적화할 수 있는 방법이 무엇이 있을까요?
0
95
2
좋아요 기능 정합성 보장 방법
0
90
2
좋아요 동시성처리 최적의 선택?
1
115
2
프론트엔드 msa 환경 api 주소 통합? 과 서버끼리 통신 방식에대해
0
85
2
안녕하세요 무한스크롤 강의듣다가 질문이 있습니다.
0
54
1
조회수 조회 로직 질문
1
64
2
비로그인 유저도 어뷰징 방지 정책
1
63
2
CommentServiceTest의 테스트 로직 질문
0
50
2
무한 스크롤 방식에서 페이지 번호 방식 쿼리의 문제점 의문
1
69
2
path 쿼리 관련 질문드립니다!
0
55
2
antigravity 에디터를 쓰신다면 종료해주세요
1
122
0
프로젝트 구조
0
83
2
article_like_count api test
0
70
2
이벤트 페이로드 객체의 생성 방식이 팩토리 메서드 패턴이 아닌 빌더 패턴인 이유가 궁금합니다!.
0
101
2
[33. 좋아요 수 구현] 에서 테스트 하는 화면 동시성 문제
0
88
2
findByPath에서 articleId로도 검색을 해야 할 것 같아요.
0
87
3
jpa ddl-auto none을 하는 이유와 join 방법
0
92
2
커서 기반 페이지네이션 과 무한 스크롤링
0
97
2
게시글 생성 로직에서 오류 발생시 redis 게시글 수 되돌리기
0
95
2
멀티 모듈이 아닌 MSA 환경에서 common
0
146
2
2Depth 강의 도중 궁금한 점 있어요!!
0
73
2
샤딩에 대해서 궁금점있습니다.
0
112
2