배달 레전드 프로젝트 회고 (정적 팩토리 메서드, 전략 패턴, 퍼사드 패턴, QueryDSL @Query 차이, Page, JPA N+1 문제)
배달 레전드 프로젝트가 끝이 났다
아쉬운 점도 많지만! 팀원들과 협업하면서 배우고 얻은 것이 많기에 회고하면서 정리하고자 한다.
1. 협업
협업은 기존대로 디스코드와 깃허브를 활용하여 진행했다.
깃허브에 issue, PR 을 발행하면 디스코드에 메시지가 오도록 설정하였다.
Github를 사용하여 프로젝트를 체계적으로 관리하고, 효율적으로 협업할 수 있도록 하였다.
`Project Board`를 통해 이슈들에 대한 전체적인 진행 상황을 파악하고 컨트롤할 수 있었다.
또 팀원 간 적극적인 코드 리뷰를 통해 코드 품질을 높이고 팀원 간 지식을 공유하였다.
2. 디자인 패턴
팀에 엄청난 실력자 분이 계셔서 다양한 디자인 패턴도 배울 수 있었다!
정적 팩토리 메서드
`정적 팩토리 메서드`는 객체 생성을 위해 정적(static) 메서드를 사용하는 기법이다.
이는 특정 디자인 패턴에 속하지는 않지만, 객체 생성 방식 중 하나로 `팩토리 패턴`의 변형으로 간주될 수 있다. 특히, 정적 팩토리 메서드는 객체 생성을 담당하면서도 객체의 생성을 `캡슐화`하여 더 유연하게 사용할 수 있는 방법을 제공한다.
정적 팩토리 메서드는 이름에서 알 수 있듯, 인스턴스를 생성하기 위해 인스턴스 메서드가 아닌 정적 메서드를 사용한다. 이 메서드는 생성자를 직접 호출하는 대신, `정적 메서드`를 통해 `객체 생성`을 제어하거나 특정 규칙에 따라 다양한 객체를 반환할 수 있다.
`특징`
- 클래스 외부에서 객체를 만들 때 여러 이름의 정적 메서드를 제공할 수 있음
- 반한 타입이 해당 클래스 자체가 아닌 해당 클래스의 하위 클래스일 수도 있음
- 싱글톤 패턴과 결합하여 이미 생성된 인스턴스를 반환할 수 있음
`장점`
- 생성자와 달리 `이름`을 가질 수 있어 목적을 명확하게 설명
- 자주 생성되는 객체는 정적 메서드에서 캐싱하여 성능 개선
- 싱글톤과의 결합 - 만약 미리 만들어둔 객체가 있다면 생성하지 않고 반환
`예시 코드`
public class Notification {
private String message;
// 1. private 생성자
private Notification(String message) {
this.message = message;
}
// 2. 정적 팩토리 메서드
public static Notification createEmailNotification(String message) {
return new Notification("Email: " + message);
}
public static Notification createSmsNotification(String message) {
return new Notification("SMS: " + message);
}
}예시 코드를 보면 기존 생성자로 객체를 생성하는 방법과 달리, static 메서드를 내에서 객체를 생성한다.
class Post {
private static final Post post = new Post("", "");
private String title;
private String writerName;
private Post(String title, String writerName) {
this.title = title;
this.writerName = writerName;
}
static Post createBasicPost() {
return post;
}
}싱글톤과 결합한 예시 코드는 위와 같다.
`from() of() 메서드`
두 메서드 이름은 정적 팩토리 메서드에서 자주 사용하는 네이 컨벤션이다.
`of 메서드`
of 메서드는 여러 개의 인자를 받아 객체를 생성할 때 사용된다. 주로 입력된 값을 사용하여 객체를 빠르게 생성하는 경우에 적합하다.
public class Post {
private String title;
private String writerName;
private Post(String title, String writerName) {
this.title = title;
this.writerName = writerName;
}
// 여러 인자를 받아서 객체를 생성하는 'of' 메서드
public static Post of(String title, String writerName) {
return new Post(title, writerName);
}
}
public class Main {
public static void main(String[] args) {
Post post = Post.of("Hello World", "Alice");
System.out.println(post);
}
}
`from 메서드`
from 메서드는 주로 하나의 입력값을 받아 그 값에서 객체를 생성한다. 특정 `타입`이나 `데이터`를 다른 형태의 객체로 변환한다.
public class Post {
private String title;
private String writerName;
private Post(String title, String writerName) {
this.title = title;
this.writerName = writerName;
}
// 하나의 입력 데이터를 받아 객체를 생성하는 'from' 메서드
public static Post from(PostDTO dto) {
return new Post(dto.getTitle(), dto.getWriterName());
}
}
// DTO 클래스
public class PostDTO {
private String title;
private String writerName;
// constructor, getters and setters
}
public class Main {
public static void main(String[] args) {
PostDTO dto = new PostDTO("Post Title", "Bob");
Post post = Post.from(dto); // DTO를 사용해 Post 객체 생성
System.out.println(post);
}
}`of` 메서드는 `DTO`에서 엔티티를 받아 `DTO`로 반환할 때도 자주 사용된다.
나는 이번 프로젝트에서 `of` 메서드에 복잡한 로직을 추가하여 사용하기도 하였다.
public static SearchShopResponse of(Shop shop, String keyword) {
return new SearchShopResponse(shop.getId().toString(), shop.getName(),
shop.getDescription(), shop.getStatus().getDescription(),
shop.getMenus().stream().map(menu -> menu.getName())
.filter(name -> name.contains(keyword))
.limit(3)
.collect(Collectors.toList()));
}
그런데 이는 좋은 설계가 아닌 것 같다.. 하나의 메서드에 너무 많은 작업을 수행하여 `단일 책임 원칙`을 위반한다!
정적 팩토리 메서드는 `객체 생성`에 집중하는 것이 좋다.
public static SearchShopResponse of(Shop shop, String keyword) {
return new SearchShopResponse(shop.getId().toString(), shop.getName(),
shop.getDescription(), shop.getStatus().getDescription(),
getFilteredMenuNames(shop, keyword));
}
private static List<String> getFilteredMenuNames(Shop shop, String keyword) {
return shop.getMenus().stream()
.map(menu -> menu.getName())
.filter(name -> name.contains(keyword))
.limit(3)
.collect(Collectors.toList());
}이런 식으로 메서드를 분리하여 `of` 메서드를 객체 생성에만 집중하게 하고 가독성을 높일 수 있다!
전략 패턴
전략 패턴은 내가 직접 구현한 부분은 아니지만, 다른 팀원분이 사용하셔서 "아, 이런 게 있구나!" 하고 알게 되어 정리한다.
`전략 패턴`은 `행위 디자인 패턴` 중 하나로 특정 작업을 수행하는 `전략(알고리즘)`을 정의하고 알고리즘을 런타임에 변경할 수 있도록 만드는 패턴이다.
즉, 전략 패턴을 사용하면 객체 행위를 정의하는 부분을 별도로 분리해 관리하고, 상황에 따라 다른 전략을 적용할 수 있게 된다.
`전략 패턴의 개념`
- `전략` 특정 동작을 정의한 인터페이스/ 추상 클래스
- `구체적 전략` 전략 인터페이스를 구현한 여러 클래스 (각각 다른 알고리즘을 가짐)
- `컨텍스트` 전략을 사용하는 클래스, 행위 실행
`예시 코드`
// 신용카드 결제 전략
public class CreditCardPayment implements PaymentStrategy {
private String cardNumber;
public CreditCardPayment(String cardNumber) {
this.cardNumber = cardNumber;
}
@Override
public void pay(int amount) {
System.out.println(amount + "원 결제 완료 (신용카드: " + cardNumber + ")");
}
}
// 페이팔 결제 전략
public class PaypalPayment implements PaymentStrategy {
private String email;
public PaypalPayment(String email) {
this.email = email;
}
@Override
public void pay(int amount) {
System.out.println(amount + "원 결제 완료 (Paypal: " + email + ")");
}
}이런 식으로 `PaymentStrategry` 인터페이스를 `CreditCardPayment` `PaypalPayment` 클래스가 구현하여 같은 작업을 다른 전략으로 수행하도록 한다.
@RequiredArgsContructor
public class ShoppingCart {
private PaymentStrategy paymentStrategy;
// 결제 요청
public void checkout(int amount) {
paymentStrategy.pay(amount);
}
}그 뒤 `Context` 클래스에서 전략을 설정하고
public class Main {
public static void main(String[] args) {
ShoppingCart cart = new ShoppingCart();
// 신용카드 결제 설정
cart.setPaymentStrategy(new CreditCardPayment("1234-5678-9876-5432"));
cart.checkout(10000); // 10000원 결제 완료 (신용카드)
// Paypal 결제 설정
cart.setPaymentStrategy(new PaypalPayment("user@example.com"));
cart.checkout(20000); // 20000원 결제 완료 (Paypal)
}
}사용할 때 알맞은 구체적 전략 클래스를 생성하여 설정한다.
너무 재미있다.. 이런 식으로 인터페이스와 구현체를 활용할 수 있다니! ㅠㅠ 디자인 패턴이 이렇게 재밌는 것일 줄야.
우리 팀에서는 아래 방식처럼 전략 패턴을 사용했다.
`실제로 사용한 코드`
@Component
@RequiredArgsConstructor
public class SignUpFacade {
private final UserRepo userRepo;
private final List<CreateUserService> createUserServices;
public Long signUp(SignUpRequest signUpRequest) {
validate(signUpRequest);
return createUserServices.stream()
.filter(it -> it.isMatched(signUpRequest.signUpType()))
.findAny()
.orElseThrow()
.createUser(signUpRequest)
;
}
}`SignUpFacade` 클래스는 전략 패턴을 활용하여 다양한 사용자 생성 서비스를 동적으로 실행한다.
`SignUpFacade`는 전략 패턴의 컨텍스트 역할을 한다. `createUserServices` 리스트에 주입된 여러 전략 객체 중에서, `signUpRequest`의 `SignUpType`에 맞는 전략을 찾아 사용자 생성 로직을 위임한다.
`findAny()`는 필터링된 결과 중 아무거나 하나를 찾는다.
일반적으로 여러 서비스 중 조건에 맞는 서비스가 하나만 존재할 것이기에, 해당 조건을 만족하는 서비스 중 하나를 반환한다.
조건에 맞는 서비스가 없을 경우 `orElseThrow()`로 예외를 던진다!
public interface CreateUserService {
Long createUser(SignUpRequest signUpRequest);
boolean isMatched(Role role);
}`CreateUserService` 전략 인터페이스는 `isMatched`를 통해 주어진 `Role`에 맞는 전략인지 판별하여 `createUser` 메서드로 사용자를 생성한다.
정리하자면 `CreateUserService`로 전략 인터페이스를 정의하고
각기 다른 알고리즘을 구현한 여러 구체적 전략 클래스를 구현하여
`SignUpFacade` 컨텍스트 클래스에서 요청에 맞는 전략을 선택하여 실행한다.
이를 통해 사용자 생성 로직을 전략 패턴으로 효과적으로 관리할 수 있다.
다음 프로젝트에서도 역할에 따라 서비스 로직을 정의할때 이런 `전략 패턴`을 사용하면 좋을 것 같다!
퍼사드 패턴
위에 클래스명을 보면 `SignUpFacade`인데.. `Facade` 즉 `퍼사드 패턴`은 무엇일까?
`퍼사드 패턴`은 복잡한 시스템을 간단하게 사용할 수 있도록 단일 인터페이스를 제공하는 디자인 패턴이다. 클라이언트는 퍼사드 인터페이스를 통해 복잡한 서브시스템과 상호작용하며, 복잡성을 감추고 시스템을 단순하게 사용할 수 있다.
`퍼사드 패턴의 개념`
- `복잡한 서브시스템`
- `퍼사드` 복잡한 서브 시스템을 감싸는 단순한 인터페이스를 제공하는 클래스
- `클라이언트` 퍼사드를 사용하는 객체
위의 `SignUpFacade`는 퍼사드 패턴을 잘 구현한 예이다.
클라이언트는 `SignUpFacade`의 `signUp` 메서드를 호출하기만 하면, 회원가입에 대한 모든 로직이 내부적으로 처리된다.
실제로 회원가입을 처리하는 것은 여러 전략의 `CreateUserService`이지만 `SignUpFacade`는 이러한 여러 전략들을 추상화한 인터페이스로 감싸서 클라이언트에게 노출하지 않는다.
즉, 클라이언트는 여러 `CreateUserService` 구현체의 존재나 구체적인 동작 방식을 알 필요가 없고, 그저 `signUp()` 메서드를 통해 회원가입을 요청할 수 있다. `SignUpFacade`는 이러한 복잡성을 모두 감추고, 간단한 방식으로 복잡한 로직을 실행하는 역할을 수행한다.
`예시 코드` 홈 씨어터 시스템
이런 식으로 활용할 수 있다.
class TV {
public void on() {
System.out.println("TV가 켜졌습니다.");
}
public void off() {
System.out.println("TV가 꺼졌습니다.");
}
}
class DVDPlayer {
public void play() {
System.out.println("DVD가 재생됩니다.");
}
public void stop() {
System.out.println("DVD 재생이 중지되었습니다.");
}
}
class SoundSystem {
public void setVolume(int volume) {
System.out.println("사운드 시스템 볼륨이 " + volume + "으로 설정되었습니다.");
}
}다양한 서브시스템 클래스들이 존재한다.
class HomeTheaterFacade {
private TV tv;
private DVDPlayer dvdPlayer;
private SoundSystem soundSystem;
public HomeTheaterFacade(TV tv, DVDPlayer dvdPlayer, SoundSystem soundSystem) {
this.tv = tv;
this.dvdPlayer = dvdPlayer;
this.soundSystem = soundSystem;
}
public void startMovie() {
System.out.println("영화 시작 준비...");
tv.on();
dvdPlayer.play();
soundSystem.setVolume(10);
}
public void endMovie() {
System.out.println("영화 종료...");
dvdPlayer.stop();
tv.off();
}
}`퍼사드 클래스`는 복잡한 서브 시스템을 감싸는 단일 진입점 역할을 하는 인터페이스를 클라이언트에게 제공하여 단순하게 처리할 수 있도록 한다.
public class Client {
public static void main(String[] args) {
TV tv = new TV();
DVDPlayer dvdPlayer = new DVDPlayer();
SoundSystem soundSystem = new SoundSystem();
// Facade를 통해 복잡한 시스템을 간단하게 제어
HomeTheaterFacade homeTheater = new HomeTheaterFacade(tv, dvdPlayer, soundSystem);
homeTheater.startMovie(); // 영화 시작
homeTheater.endMovie(); // 영화 종료
}
}실제 클라이언트에서는 간단한 메서드 호출만으로 복잡한 로직을 수행할 수 있다.
3. QueryDSL @Query 차이
이번 프로젝트에서 `QueryDSL`을 사용해보았다.
처음 사용해봐서 우여곡절이 있었지만.. 잘 해낸 것 같다 ^^ 다음에도 활용해 보고 싶당
`QueryDSL`과 `@Query` 특징과 차이점을 정리해보고자 한다.
QueryDSL
- `타입 안전성` QueryDSL은 타입 안전한 쿼리를 작성할 수 있게 해준다. 컴파일 타임에 쿼리의 유효성을 검사할 수 있어, 문법 오류나 잘못된 필드 접근을 미리 확인할 수 있다.
- `자바 코드 기반` 쿼리를 자바 코드로 작성하므로, 동적 쿼리 생성이나 복잡한 쿼리 로직을 자바 코드로 표현할 수 있다. 이는 조건문, 반복문 등을 사용하여 유연하게 쿼리를 구성할 수 있음을 의미한다.
- `자동 코드 생성` QueryDSL은 메타 모델 클래스를 자동으로 생성한다. 이 메타 모델 클래스는 엔티티 클래스의 필드와 메서드를 기반으로 쿼리를 작성할 때 사용된다.
- `설정 필요` QueryDSL을 사용하려면 추가적인 설정과 의존성 추가가 필요하며, 메타 모델 클래스를 생성하는 과정이 필요하다.
@Query
- `문자열 기반 쿼리` @Query 애노테이션을 사용하면 JPQL 또는 네이티브 SQL 쿼리를 문자열로 직접 작성할 수 있다. 이 방법은 쿼리를 명시적으로 작성하므로 쿼리 작성이 직관적일 수 있다.
- `동적 쿼리` 기본적으로 @Query는 동적 쿼리 생성에 적합하지 않다. 하지만, Spring Data JPA의 @Quer와 SpEL (Spring Expression Language)을 조합하여 동적 쿼리를 작성할 수 있다.
- `설정 필요 없음` QueryDSL과 달리 별도의 설정이나 메타 모델 클래스를 필요로 하지 않다. 간단하게 쿼리를 직접 작성할 수 있어 설정이 간편하다.
- `문자열 오류` 쿼리를 문자열로 작성하기 때문에 문법 오류가 컴파일 타임이 아닌 런타임에 발생할 수 있다. 이로 인해 쿼리 오류를 찾기 어려울 수 있다.
정리하면!
- `QueryDSL` 타입 안전하고 동적 쿼리 작성에 적합, 자바 코드로 쿼리 작성, 추가 설정 필요
- `@Query` 문자열로 직접 쿼리 작성, 설정이 간편하지만 문법 오류가 런타임에 발견될 수 있음
5. Page 객체 사용
프로젝트에 페이징 처리를 위해 Page 객체를 사용하면서 많은 것을 알게 되었다.
특히, Page 객체가 `stream` 타입으로 동작하여 `stream()` 메서드를 호출하지 않아도 `map()` 메서드를 사용할 수 있다는 점이 신기했다.
가장 충격적이었던 것은 PageImpl<>을 생성할 때 데이터의 총 개수를 잘못 설정했던 부분이다.
나는 처음에 페이지당 데이터 개수, 즉 size만큼의 데이터를 전체 데이터 개수로 넣었는데, 이는 완전히 잘못된 방법이었다. 정확히는 PageImpl<>을 생성할 때 전체 데이터의 총 개수를 넣어줘야 했다.
전체 데이터 개수를 알아야 페이지 수를 정확히 계산할 수 있고, 현재 어떤 페이지를 불러와야 하는지도 알 수 있기 때문이다. 페이지당 데이터 개수만으로는 전체 데이터의 양을 알 수 없기 때문에 페이지 수를 제대로 계산할 수 없다는 것을 깨달았다.
근데 생각해보니 당연하다.. ㅋㅋㅋ 그래야 페이지당 데이터 개수를 기준으로 몇 페이지가 필요한지 알고, 현재 페이지를 정확히 불러올 수 있게 된다. 이번 경험 덕분에 페이징 처리에 대한 이해가 확실히 깊어졌다.
public Page<SearchShopResponse> search(PageRequest pageRequest, String keyword) {
Page<Shop> shops = shopRepository.search(pageRequest, keyword);
return shops.map(shop -> SearchShopResponse.of(shop, keyword));
}그냥 PageImpl<> 만들지 말고 Page 바로 넘겨주는 게 짱인 것 같다 ㅋㅋ
아 그리고 Page 객체의 `map()` 메서드는 기존의 객체를 새로운 형태의 Page 객체로 변환한다 짱이다!!!!!!!!!!
6. JPA N+1 문제
JPA N+1 문제에 대해서도 정리할 수 있었다.
`N+1 문제`는 JPA에서 데이터베이스 쿼리 최적화와 관련된 성능 문제로, 연관된 엔티티를 조회할 때 다수의 추가 쿼리가 발생하는 현상이다.
예를 들어, Shop-Menu 관계에서 특정 Shop의 Menu를 조회할 때, Shop 엔티티를 조회한 후 각 Shop에 대해 Menu를 가져오는 추가 쿼리가 N번 실행된다.
해결 방법으로는 `fetch join`을 사용하여 조인 쿼리를 직접 작성하거나, Hibernate의 `@BatchSize` 어노테이션으로 쿼리 수를 줄이는 방법이 있다. 또한, JPA의 `EntityGraph`를 사용하여 EAGER 로딩을 명시적으로 설정할 수 있지만, 복잡한 경우에는 사용이 어려울 수 있다.
자세하게 정리한 내용은 여기서! 확인할 수 있다.
진짜!! 의미가 컸던 프로젝트였던 것 같다.
능력자 팀원분께서 다양한 템플릿, 편리한 기능, 개발 방법.. 등등을 제공해주셔서 편하게 개발할 수 있었고 덕분에 다양한 것들을 배우고 알 수 있었다.
이제 내가 배운 것들을 내 것으로 만들기 위해, 틈틈이 복습하는 것도 중요하겠다는 생각이 든다.
완성도가 낮아서 아쉬운 부분도 있었지만, 나머지 프로젝트가 끝나고 나서 이 프로젝트를 다시 완성시키고 싶을 만큼 팀원분들이 너무 좋았다! 열정 가득한 팀원들과 함께할 수 있어서 정말 감사하고 기뻤다!