Service와 ServiceImpl을 따로 두는 이유는 뭘까?

회사에서 Spring프로젝트를 진행하면서 기존의 개발자들이

Interface의 형태로 Service와  ServiceImpl, Dao와 DaoMapper이렇게 나누어 놓는것을 흔하게 볼 수 있었다.

습관적으로 나누고, 기존의 프로젝트들이 그래왔으니까 그러려니~ 넘어갈 수도 있지만, 문득 궁금해졌다.

 

그래서 https://jeonyoungho.github.io/posts/spring%EC%97%90%EC%84%9C-Service-ServiceImpl%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%B4%EC%95%BC%ED%95%98%EB%82%98/ 글을 참고하여 기록해보려한다.

 

1. 느슨한 결합을 유지하기 위해

객체간의 결합도를 낮추어 변화에 유연한 개발을 하기 위해서라고한다. 

하나의 인터페이스를 구현하는 여러 구현체가 있고, 기능에 따라 적절한 구현체가 들어가서 

다형성을 주기 위함이라 한다.

현재 내가 진행하는 프로젝트는 1개의 서비스에 1개의 impl만 붙기때문에 이부분을 생각 못한거같다. 

후에 프로젝트에서 다중상속인터페이스를 활용할 일이 생기면 한번더 정리해보도록 하겠다.

 

2. AOP Proxy를 위하여

스프링은 JDK Dynamic Proxy를 사용하여 인터페이스 기반으로 만들어진다고 한다.

인터페이스가 존재해야 @Transactional같은 어노테이션이 작동하는것이다.

하지만 최근에는 잘 사용하지 않는다.

 

결론적으로 보면 느슨한 결합과 다형성을 위해 인터페이스를 사용하는거같다.

하지만 최근 프로젝트들이 너~무 느슨해져서 하나의 클래스가 Mini를 넘어 Micro로 변한 느낌이 든다.

"왜" 인터페이스를 사용하는지는 잘 알겠다.

하지만 꼭 써야하나? 에 대한 질문이 온다면 나는 "굳이?" 라고 답하고싶다