Spring service, serviceImpl?

학부시절에 Spring을 MVC구조로 Controller, Service, Dao로 구분하여 Spring을 배웠다.

지나온 개인프로젝트 또한 동일하게 구분하여 개발을 진행했다.

넥스젠에 재직당시 전자정부프레임워크의 프로젝트를 유지보수하는 업무를 받아 코드를 살펴보았다.

그런데 Service를 Service인터페이스와 ServiceImpl 클래스로 나누어 구현하였다.

<br/>

구글 검색을 해보니 대부분 위와 같이 Service를 나누어서 구현하였다.

Service 인터페이스를 상속받는 서브클래스는 ServiceImpl 클래스 하나 뿐이었다

인터페이스와 서브클래스는 1:1 관계로 구현되어 있다.

1:1 관계이면 다형성도 굳이 필요가 없는데..

<br/>

이유가 궁금하였다.. 왜굳이 나눌까?

<br/>

구글 검색을 해보았는데, 지니어스 개발자 분들이 쓴 내용들이 어느정도 일치하였다.

객체지향원리인 OCP 원칙을 보자. 확장에는열려있고 변화에는 닫혀있어야 한다.

Service는 비즈니스로직을 담당한다. Controller는 Service 인터페이스를 참조한다. ServiceImpl은 Service 인터페이스를 상속받아, 구현한다.

새로운 기능을 추가하였을때, 코드의 변화없이 B_ServiceImpl을 Service 인터페이스를 상속받아 구현함으로써, 확장에는 열려있고, 변화에는 닫혀있도록 하는 것이다.

추후 어떠한 기능적 추가, 고객의 요구사항 추가, 비즈니스 로직 추가에 다양한 변동성에 대응하기 위함이다.

<br/>

그러나 지니어스 개발자분들은 ServiceImpl을 사용하는 것에 부정적인 의견을 보였다.

대부분의 프로젝트를 진행해오며 ServiceImpl과 Service 클래스간의 1:1 구조이기 때문에

쓸데없이 모든 Service를 인터페이스/서브클래스로 나누어 구현하는 것은 생산성 낭비라고 보는 입장이다.

<br/>

이 문제는 프로젝트에 따라, 또는 현업이 들어가 더 생각해봐야 할 것 같다.

다만 "다 그렇게 쓰는데?" 라고 기계적으로 코딩하는것은 아니라 생각하기에 정리해본다.

<br/>

참조.

<a href="https://cheese10yun.github.io/spring-oop-04/">https://cheese10yun.github.io/spring-oop-04/</a>

<a href="http://multifrontgarden.tistory.com/97">http://multifrontgarden.tistory.com/97</a>