스프링 - OCP와 Service

Annotation 동작 원리 찾다가 @Service를 봤고 그걸 보고 프로젝트에서 Service를 인터페이스와 구현체로 리펙토링 하려고 했다는 사실을 기억해냈다.
근데 왜 그래야 하지?라는 질문에 답을 못했다.

왜 service는 interface와 구현체로 작성해야하는가에 대한 해답을 찾는데 큰 도움이 된 블로그입니다!
👉🏻우리집 앞마당님 블로그 바로가기

왜 service와 seviceImpl로?

지금 까지 진행했던 프로젝트가 4개 정도 되는데 그 중 하나의 프로젝트만 service를 interface와 implement로 나눴다.
사실 나보다 잘 하는 사람이 나누자고 해서 오... 그게 맞나보네라고 무지성으로 따라갔는데 지금 생각해봐도 왜 나눈지 모르겠다.

그때 인터페이스와 구현체의 비율이 1:1이었고 서비스 객체간의 연관성도 없었다.

SOLID원칙 중에 OCP 개방-페쇄원칙을 지키고자 인터페이스와 구현체를 나눈 것 같다.
service와 그걸 구현하는 구현체가 2개 이상이면 그 의미가 있을 것 같은데(확장을 한다면) 지금까지 했던 프로젝트는 그렇게 진행하지 않았다.

결론

OCP를 지키면서 인터페이스-구현체 형식을 더욱 의미있게 사용하려면 기본적으로 구성했던 service interface를 상속한 확장기능이 있는 클래스를 작성해서 확장기능이 필요한 메서드에서 DI를 통해 접근해야할 것 같다.