Service와 ServiceImpl

 

다른 프로젝트들을 구경하면 Service 인터페이스와 ServiceImpl 클래스(구현부)를 따로 두어 코딩을 진행하는 경우를 많이 봤다. 

왜 굳이 나눌까 궁금해서 서칭을 하고 기록을 남겨볼까 한다.

 

우선 두 가지로 왜 나누어놓는 지를 알기 위해서는 OOP(객체 지향 프로그래밍)에 대한 이해가 필요하다.

OOP를 완전히 이해하는 것은 어려운 일이지만, 짧게 말하면 '객체'들의 모임이다. 

OOP는 프로그램을 유연하고 변경이 용이하게 만들기 때문에 SW개발에 많이 사용된다.

 

Service와 SeviceImpl은 다형성과 연관이 있다. 

다형성이란 하나의 객체가 여러가지 타입을 가질 수 있는 것을 의미하는데, 보통 부모 클래스를 자식이 상속받아 기능을 확장하거나 변경하는 방식으로 사용을 많이 한다.

즉, Service를 부모로 인터페이스로 만들고, 자식으로는 ServiceImpl 클래스가 부모를 상속받아 구현하게 된다.

~Impl이 붙는 것은 개발자들이 따르는 naming convention이다.

 

그래서 대체 왜 사용할까?

 

인터페이스는 객체의 사용 방법을 정의한 타입으로도 볼 수 있다. 객체의 교환성을 높여주기 때문에 다형성을 구현하는 데 매우 중요하다. 즉, 개발 코드를 수정하지 않고 사용하는 객체를 변경할 수 있도록 해준다.

클래스 간의 의존 관계를 줄여 결합도를 낮춰주는데도 좋은 방식이다.

느슨한 결합을 뜻하는데 loose coupling이라고 한다. 의존 관계를 최소화해서 기능 변화에도 최소한의 수정으로 개발할 수 있다. 모듈화를 통해 어디서든 사용할 수 있도록 재사용성이 좋다.

스프링의 IOC/DI 기능을 이용해 빈 관리 기능이 사용이 가능하다고 하는데 이 부분은 조금 더 공부해봐야 할 것 같다.

 

그래서 이런 구조를 그냥 따르면 될까?

 

다른 블로그를 많이 찾아봤지만, 물론 부정적인 시각도 있었다.

내가 궁금했던 것이 바로 Service 인터페이스와 ServiceImpl이 1:1로 매핑이 된다면 굳이 필요할까? 였다

괜히 하나의 인터페이스가 더 늘어나는 셈인 것 같았다. 그래서 1:1이라면 굳이 인터페이스를 둘 필요가 없다고 생각한다.

단, 1:N 구조에서는 사용하는 것이 좋을 것 같다. 

하나의 작업으로 인해 N(N>=2)개 이상의 작업이 수행되거나, 추가될 예정인 경우에는 인터페이스를 따로 두어 관리하는 것이 좋을 것 같다. 추가될 예정인 경우가 애매하다고 보지만 그만큼 자신이 수행중인 업무를 제대로 이해하는 능력 또한 중요한 것 같다.

 

생각

 

단순히 남들도 이렇게 하니까~ 라는 생각보다 왜 쓰게 되었는 지 왜 이렇게 많이들 쓰는 지를 이해하고 부정적인 시각도 많이 보면서 사용법을 제대로 익혀가는 것이 좋은 것 같다.