관습적인 추상화 service와 serviceImpl

목표

일반적으로 Service 인터페이스와 ServiceImpl은 1:1인 경우가 많은데, 굳이 인터페이스와 구현체를 나눠놓은 이유가 뭔지에 대해서 작성해보기!

내용

많은 프로젝트에서 MVC 구조를 많이 채택하며, Service코드를 작성할 때 Service와 ServiceImpl로 작성하는 경우가 많은데 관습적으로 이렇게 하는경우가 많다보니 “대부분 이렇게 하던데?”라는 생각으로 따라하게 되었는데 문득 궁금증이 들게 되었습니다.

사실 Service와 ServiceImpl은 1:1인 경우가 대부분이어서 오히려 작성해야하는 코드만 늘어난다는 생각이 문득 들었습니다.

• 일반적인 service, serviceImpl 코드

interface ProductService {

    List<Product> getProductList();

}

class ProductServiceImpl extends ProductService {

	@override 
	public List<Product> getProductList();

}

그래서 왜 이런 관습적인 서비스 클래스의 추상화 구조가 생기게 되었는지에 대해서 알아보게 되었는데, 가장 큰 이유 중 하나는 프록시였습니다.

과거의 spring 버전( Spring 4 이전) 에서는

Spring에서는 AOP를 적용하기 위해 porxy를 사용하는데 예전에는 JDK Dynamic Proxy를 사용했고 이 proxy방법을 사용하기 위해서는 interface가 존재했어야 했습니다.

그래서 이때는 Spring에서 권장하는 방법으로 proxy를 하기 위해서 1:1이지만 Service 인터페이스와 구현체를 나누어서 했던 관습이 남아 있는것으로 보입니다.

결론

현재는 CGLIB의 문제점이 해결되어 CGLIB를 기반으로 proxy를 만들도록 설정(기본 값)되어 있고, 그래서 위에 말했던 관습적인 구조를 따를 필요가 없습니다. 굳이 나누어도 이득이 없고 코드의 구현량이 늘어나기 때문에 한 인터페이스에 대한 구현체가 2개 이상일 가능성이 있지 않다면 추상화를 할 필요성이 없지 않나 하는것이 제 생각입니다.

 

하지만 실무에서는 개인의 의견만으로 마음대로 코드를 작성할 수 없기 때문에 기존 프로젝트에 개발되어 있던 구조를 무시하고 개발 할 수는 없고 팀원과 협의가 이루어 져야 한다고 생각합니다.

 

읽어주셔서 감사합니다.

 

 

 

 

 

 

 

 

참고: https://gmoon92.github.io/spring/aop/2019/04/20/jdk-dynamic-proxy-and-cglib.html