[TIL] Spring - Service와 ServiceImpl을 나누는 이유

1. Service, ServiceImpl

이전에 일정 관리 프로젝트를 할 때에는 미처 적용을 하지 못 했었는데요
강의를 다시 이어서 보고있으니 Service와 ServiceImpl을 나누어서 사용하더라구요

public interface ScheduleService {
}

@Service
public class ScheduleServiceImpl implements ScheduleService {
   // 서비스 레이어 구현
}

다른 개발자들이 사용하는 데에는 이유가 있을테니 자세히 알아보도록 하겠습니다

---

2. Interface를 쓰는 이유부터

사실 List, Map, Set 들도 인터페이스인데 각각 LinkedList, HashMap, HashSet을 사용할 수 있구요
아니면 각각 ArrayList, TreeMap, LinkedHashSet으로 바꿔서 사용할 수도 있습니다

List<Integer> list = new LinkedList<>();
Map<String, String> map = new TreeMap<>();
Set<Integer> set = new HashSet<>();

그러면 List를 LinkedList 또는 ArrayList로 사용하듯이
스프링 개발을 하면서 개발 환경과 배포 단계의 로직을 다루게 구성하는 것도 손쉽게 할 수 있지 않을까요
또는 서비스가 점점 커지면서 구현체 클래스가 확장된다면 유연하게 대처하는 것도 가능할 것이구요

---

3. 협업할 때에도

프로젝트 개발은 협업이 매우 중요하죠

컨트롤러와 서비스 레이어를 담당하는 팀원이 있을 때 만약 설계도같은 인터페이스를 설계해두면
팀에서 컨트롤러 쪽은 구현체를 자세히 알 필요도 없고 서비스측은 어떤 것을 개발하면 되는지 알기 쉬울 것 같습니다

굳이 팀원이 아니더라도 길게 서비스를 작성했던 개발자도 어떤 메서드들을 작성했었는지 보기도 편하구요

---

4. 근데 꼭 나누어야 할 필요가 있나?

사용하는 이유가 있을테니 차근차근 찾아보았는데 실무에서 사용을 안하는 입장도 꽤 있는 편입니다

• 불필요한 추상화 : 굳이 1개로 정해진 서비스의 인터페이스(1:1 구조)를 만들 필요 X
• 단위 테스트의 어려움 : 인터페이스와 구현체를 모두 생성해야 하며 의존성이 높아져 복잡해짐

그리고 결론도 대부분 비슷하게 도출되었습니다

구현체를 쉽게 교체해야 하는 경우에 적용할 수도 있고 그 외엔 아닐 수도 있고..
정답은 따로 없다

즉, 개발하고자 하는 프로젝트와 개발자의 역량에 따라 결정하는 것이 좋을 것 같은데..

저는 현재로써 굳이 필요하지는 않겠지만, 그래도 언젠가 서비스가 커지는 프로젝트를 할 수도 있으니
이번 내용을 알아둬도 나쁠 것은 전혀 없다고 생각합니다