OCP와 DIP를 지키기 위해
인터페이스와 구현체를 분리하고 다형성을 갖게끔 하는게 좋은 코드란건 알겠고,
결국 인터페이스를 상속받고 필요한 구현체만 구현하면 된다는걸 다들 알겠다고 한다.
근데 정작 사용을 어떻게 하는지 대부분 모르는 것 같다.
일단 개인적으로 그다지 좋지 않은 코드의 예시다.
public interface PayService {
void pay();
}
private class PayKakaoService implements PayService {
@Override
public void pay() {
}
}
private class PaySamsungService implements PayService {
@Override
public void pay() {
}
}
private class PayNaverService implements PayService {
@Override
public void pay() {
}
}
private PayService payKakaoService;
private PayService paySamsungService;
private PayService payNaverService;
@Getter
@RequiredArgsConstructor
public enum PayType {
Kakao, Samsung, Naver;
}
@PostMapping("/payment")
public ResponseEntity<?> pay(PayType payType) {
if (payType == PayType.Kakao) {
payKakaoService.pay();
}
if (payType == PayType.Samsung) {
paySamsungService.pay();
}
if (payType == PayType.Naver) {
payNaverService.pay();
}
return ResponseEntity.ok().build();
}
// 실행
void callPayTest() {
this.pay(PayType.Samsung);
}위 코드의 단점이 뭘까? 분명 인터페이스도 썻고, 필요에 따라 구현체도 만들었고,
근데 저기에 앱쁠페이를 추가한다면? 구현체를 만들지만
public ResponseEntity<?> pay(PayType payType)요기 안에 있는 if문을 추가해야 하지 않겠는가?!
이거는 DIP에 위배 되는게 아닌가? 싶기도 하고,
PayService ps = null;
if (payType == PayType.Kakao) {
ps = payKakaoService;
}
if (payType == PayType.Samsung) {
ps = paySamsungService;
}
if (payType == PayType.Naver) {
ps = payNaverService;
}
ps.pay();아님 뭐 메서드 내 필드를 이용해서 이렇게 바꿀까? 이것도 뭐 크게 다른건 없다고 느끼는데,
그렇다고 싱글톤 기반의 빈에서 클래스 필드를 맘대로 교체할 수도 없는 노릇이고,
좀 더 고차원 레이어에 영향이 안가는 방법의 코드를 작성 할 수는 없을까?
있다, Enum과 Provider를 사용하면 된다.
Spring Container는 등록된 모든 Bean에 대한 제어가 가능하다.
일단 등록되어 있으니 가져오는 것도 가능하다.
구조적으로는 위에 if문을 사용하는 것과 차이가 없지만,
적어도 인터페이스를 호출 하는 부분을 타입이나, 유형 때문에 바꿀 일은 없을 거다.
예시 코드 들어간다.
참고로 제 코드가 좋은 코드는 아닙니다용..제발...
public interface PayService {
void pay();
}
private class PayKakaoService implements PayService {
@Override
public void pay() {
}
}
private class PaySamsungService implements PayService {
@Override
public void pay() {
}
}
private class PayNaverService implements PayService {
@Override
public void pay() {
}
}
// private PayService payKakaoService;
// private PayService paySamsungService;
// private PayService payNaverService;
@Getter
@RequiredArgsConstructor
public enum PayType {
Kakao(PayKakaoService.class), Samsung(PaySamsungService.class), Naver(
PayNaverService.class);
private final Class<? extends PayService> clazz;
}
public class PayServiceProvider {
private static ApplicationContext applicationContext;
private static Map<PayType, Class<? extends PayService>> payServiceMap = new HashMap<>();
static {
for (PayType payType : PayType.values()) {
payServiceMap.put(payType, payType.getClazz());
}
}
public static PayService service(PayType payType) throws Exception {
Class<? extends PayService> payServiceClass = payServiceMap.get(payType);
if (payServiceClass == null) {
throw new Exception();
}
return applicationContext.getBean(payServiceClass);
}
}
@PostMapping("/payment")
public ResponseEntity<?> pay(PayType payType) throws Exception {
// PayService ps = null;
//
// if (payType == PayType.Kakao) {
// ps = payKakaoService;
// }
//
// if (payType == PayType.Samsung) {
// ps = paySamsungService;
// }
//
// if (payType == PayType.Naver) {
// ps = payNaverService;
// }
//
// ps.pay();
PayServiceProvider.service(payType).pay();
return ResponseEntity.ok().build();
}
// 실행
void callPayTest() throws Exception {
this.pay(PayType.Samsung);
}일단, 해당 코드는 provider에서 사용하는 applicationContext에 대한 주입이 없긴하다.
요건 이제 @PostConstruct를 사용해서 주입하면 되긴합니다요.
물론 주입하는 함수도 provider에 static으로 만들어 줘야 합니다.
(대충 읽고 코드만 복붙하면 안되게 하려는 함정...)
대강 저런식이면, 앞으로 앱쁠페이든, 티머니든 추가되면 Enum과 구현체의 추가만으로 솔리드 뭐시기를 위배하지 않으면서 해결가능하지 않을까?
사실 Provider 구현하기 귀찮다.
유지 보수 측면에서는 좋긴하나, 처음 구현할때 걍 if else 쓰는게 백배 편하다.
시간 비용을 초기에 쓸거냐 나중에 쓸거냐 차이긴한데,
아래는 좀 더 편한 방법
private List<PayService> payServices;
@PostMapping("/payment")
public ResponseEntity<?> pay(PayType payType) throws Exception {
payServices.stream().filter(payService -> payService.check(payType)).findFirst()
.ifPresent(PayService::pay);
return ResponseEntity.ok().build();
}
스프링은 주입시 배열로 필드를 선언하면 해당 인터페이스에 해당하는 빈들을 모두 가져 오는데요, 이걸 몰랐던건 아닌데, 이렇게 응용할 생각은 못 했네요. 멍청이...
아는분이 알려주신건데 아래 링크 통해 배우셨대요!
https://youtu.be/3MTf43_RcVM
'프로그래밍 > 자바' 카테고리의 다른 글
| [기록] Spring mockMvc test securityRequirements type (0) | 2024.03.17 |
|---|---|
| [issue]spring boot deploy war to external tomcat 9 (0) | 2021.07.05 |
| ubuntu openjdk 설치 (oracle java 삭제 후 zulu-8 설치) (0) | 2018.08.24 |
| Spring RestTemplate 네이버 블로그 글쓰기 API (0) | 2017.06.20 |
