Spring 개방 폐쇄의 원칙을 반영한 코드 리팩토링

📌 상황

• 팀장님께서 리팩토링한 코드를 보고 인터페이스 구현체를 명시해주는 것에 대해 고민하며 ‘Spring의 개방 폐쇄 원칙’ 개념에 대해 직접적인 이해를 하게 되었다.

 

• 현재 회사 코드는 위와 같은 구조를 가지고 있고, 지금은 SmsExternalService 인터페이스의 구현체가 SmsNaverService 뿐이지만, 만약 다른 구현체가 생긴다면, SpringBoot가 어떤 구현체를 사용해야할 지 몰라 에러가 발생할 것이다.
• 따라서 이러한 부분에 대한 리팩토링이 추가로 필요하다고 생각했다.

 

📌 개선

@RestController
public class UserV2Controller {
	private SmsExternalService smsExternalService;

	@PostMapping(..)
	public ResponseEntity<SingleResult<Dto>> userAuthPhoneNumber(@RequestBody @Valid SmsSendReqDto smsSendReqDto) {
		...
			smsExternalService = smsExternalFactory.getType(smsSendReqDto.getType()); //요청한 타입에 해당하는 구현체 반환
	}
}

• 위처럼 요청한 타입에 따른 구현체 반환을 다른 클래스(SmsExternalFactory)에서 처리하게 하여 알맞은 구현체를 반환해주도록 개선할 수 있다.

• 새로운 SMS전송 구현체가 추가된다고 하더라도(확장에 열려있음) SMS전송을 호출하는 UserV2Controller 쪽에서는 수정 없이(변경에는 닫혀 있음) SmsExternalService 확장이 가능하다. 물론 SmsExternalFactory 클래스의 의존성 주입 코드에서는 추가가 될 것이다. (어딘가에서는 처리를 해줘야 하는데, 그 어딘가가 Controller는 아니란 얘기가 됨)

 

📌 추가로 고려할 부분

• 위와 같은 코드 상황에 대해 팀장님께 공유를 드렸고, 해당 방안 이외에도 추가로 2가지 방안에 대해 알게 되었다.

• 우선, 우리 회사에서는 SMS를 1가지로만 사용할 것이기 때문에 위와 같은 설정 방안은 우선순위가 아니었다. 그 대신, @Profile 어노테이션을 사용해 특정 Service 구현체가 어떤 환경(prod, dev, test 등)에서 사용될 것인지 명시해줄 수 있고, @Qualifier 어노테이션을 사용해 Service의 구현체를 명시해주는 방향이 더 우선적으로 고려된다고 말씀해주셨다.

// @Qualifier() 적용 예시
public class UserV2Controller {
	private final SmsService smsService;

	...

	// 생성자
	public UserV2Controller(@Qualifier("SmsNaverService") SmsService smsService, ..) { // @Qualifier를 사용해 구현체 명시
		this.smsService = smsService;
		...
	}

	...
}

• 명확한 정답은 없지만, 현재 상황에서 가장 적합한 방안으로 개선하는 것이 중요하다는 것을 알게 되었다.

 

🎈참고

https://cheese10yun.github.io/spring-solid-ocp/#null