팩토리 메소드 패턴으로 리팩토링

문제상황

카카오 페이를 통해 결제를 구현했다. 코드는 전적으로 카카오페이에 의존한 상태이다.

 

문제는 새로운 결제수단이 등록 되었을 때 생긴다.

 

결제 코드가 카카오 페이에 전적으로 의존하여 기존의 코드를 다 바꿔야 한다는 문제점이 생긴다.

 

이러한 문제점을 해결하기 위해 팩토리 메소드 패턴을 이용하여 리팩토링 하였다.

 

이유

여러가지 디자인 패턴 중 팩토리 메서드 패턴을 이용한 가장 큰 이유는 객체 생성을 캡슐화 하기 때문이다.

 

객체 생성을 캡슐화를 통한 얻을 수 있는 이점은 다음과 같다.

 

• 확장성
  객체 생성 코드를 수정하지 않고도 새로운 객체를 추가하거나 기존 객체를 변경할 수 있다. 이는 시스템의 확장성을 높이는데 큰 장점이 된다.
• 코드 중복 최소화
  객체 생성 코드를 중복해서 작성하는 일이 없어지고, 코드의 중복이 최소화된다. 이는 유지보수성을 높이고, 코드의 가독성을 향상시키는데 도움이 된다.
• 결합도 감소
  객체 생성 코드와 사용 코드를 분리할 수 있다. 이는 시스템의 결합도를 감소시키는데 큰 역할을 한다.

즉, API 별로 어떤 메소드를 사용해야 할지 모르는 상황에서 가장 적합한 디자인 패턴이기 때문에 팩토리 메서드 패턴을 선택했다.

 

이전 코드

하나의 컨트롤러에서 카카오페이만을 이용하여 구현하였다.

해결 방법

1. 먼저 다음과 같이 모든 api에 존재할 것이라고 생각되는 메소드를 추상화 하였다.

2. 카카오페이에서 구현해야 하는 메소드를 위의 인터페이스를 상속받아 구현하였다.

카카오 페이를 구현하는 방법에 대한 글이 아니니 자세한 메소드는 카카오 개발자 공식 문서를 보고 사용하자.

간단히 설명하자면 요청시 필요한 헤더, 바디를 설정한 후 요청을 전송하고 요청을 받는 형식으로 진행된다.

 

3. 이후 다양한 결제 수단에 대해 유연하게 응답할 수 있도록 결제 팩토리를 생성하였다. 

구현하는 방법에는 Enum을 이용하는 방법도 있었지만, 결제 수단을 받고 이를 반환하는 방법이 생각나지 않아 Map을 통해 구현하였다.

 

간단히 코드를 설명하자면 String으로 결제 수단을 받아 결제 수단에 맞는 Service를 반환하도록 하였다.

 

4. 이후 컨트롤러를 작성하였다.

위와 같이 PathVariable을 통해 결제 수단을 받아 알맞은 경로로 리다이렉트를 해줬다.

 

API 간에 요청, 응답 메소드, url이 모두 다를 것이기에, 해당 컨트롤러에서 세부적인 결제를 구현한 것이 아닌 리다이렉트 된 컨트롤러에서 구현하였다.

 

5. 구현한 컨트롤러 

카카오페이 컨트롤러 이므로 카카오페이 서비스를 이용해 요청 응답을 구현하였다. 

 

코드를 설명하자면 결제 요청시 필요한 값을 dto에 담아 카카오페이 서비스에 보내주면 서비스 레이어에서 요청을 하고 이에 따른 응답한 url로 리다이렉트 시켜주는 코드이다. 

자세한 내용은 카카오 공식 문서에서 확인하자

느낀점

디자인 패턴을 학습한 후 팩토리 메소드 패턴을 처음 적용시켜봤다.

팩토리 클래스에서 반환한 카카오페이 서비스를 이용해 구현하는 방법이 아닌 한 개의 메소드만 이용한 후 리다이렉트된 클래스에서 새롭게 정의된 카카오페이 서비스를 이용하여 반쪽짜리 팩토리 메소드 패턴이라는 느낌이 온다.

API를 제공하는 서비스에서 리다이렉트를 자꾸 시켜 어쩔 수 없이 새로운 컨트롤러를 만들었지만, 추 후 Enum을 이용하는 방법이나 제대로 된 팩토리 메소드 패턴을 적용시킬 수 있는 방법에 대해서 고민해봐야겠다.