인프런 커뮤니티 질문&답변
작성한 질문수
서비스 계층에서 인터페이스와 Impl 구분에 대해서
해결된 질문
작성
·
749
·
수정됨
1
[질문 템플릿]
1. 강의 내용과 관련된 질문인가요? (예)
2. 인프런의 질문 게시판과 자주 하는 질문에 없는 내용인가요? (예)
3. 질문 잘하기 메뉴얼을 읽어보셨나요? (예)
[질문 내용]
안녕하세요.
다른 사람의 코드를 읽던 중에 궁금한 것이 생겨서 질문 남깁니다.
제가 읽은 코드에는 ~~Service(인터페이스) 와 ~~ServiceImp로 작성을 했습니다. 이 전에도 이런 구조를 사용하는 코드를 종종 봤습니다. 저는 지금까지 그냥 바로 인터페이스 없이 ~~Service를 만들고 비즈니스 로직을 작성 했습니다.
제가 찾아본 결과로는 인터페이스와 구현을 구분하는 이유는 2가지 였습니다.
OCP 법칙을 더 잘 지키기 위해서
추상과 구현을 OCP 법칙을 지키고 다형성을 확보하기 위해서
AOP Proxy
과거 스프링에서 AOP를 사용할 땐 JDK Dynamic Proxy를 사용하기 때문에 인터페이스가 필요했다. 하지만 지금은 GCLIB를 사용할 수 있기 때문에 사실상 의미를 잃었다.
추가적으로 인터페이스를 나누고 인터페이스에 javadoc용 주석을 남겨두면 유지보수 측면에서 읽기에 더 나은 부분이 있지 않을까 정도 생각해 보았습니다.
서비스 계층에서 인터페이스와 구현을 나누는 것과 하나의 서비스 클래스에 구현하는 것 중에 대부분의 경우 어떤 것을 더 권장하시는지 궁금합니다. 감사합니다!
답변 1
0
안녕하세요, 789456jang 님. 공식 서포터즈 y2gcoder 입니다.
서비스 계층 또한 인터페이스와 구현체로 나누어야 하는 지에 대해 질문해주셨습니다. 이것은 사람마다 생각하는 바가 달라 말씀드리기 조심스럽습니다.
저는 보통 서비스를 먼저 구현체로 만들고, 추후에 추상화가 필요할 때 인터페이스와 구현체로 분리하는 방식으로 리팩토링하자고 원칙을 세웠습니다. 왜냐하면 현업을 하면서 서비스 쪽에 추상화가 필요한 경우는 거의 없었기 때문입니다. 주로 서비스가 하는 일은 도메인 로직이나 리포지토릭의 로직들을 순서대로 실행하게끔 하는 역할을 많이 했고, 서비스에 추상화가 필요한 변경보다는 비즈니스 로직 자체의 변경이 생겨 서비스 자체를 변경해야 하는 경우가 많았습니다.
또한 무조건 인터페이스와 구현체로 나눴을 때 오히려 추상화에 대해 불필요한 이해 비용이 발생한다고 생각했습니다. 제가 다른 사람의 코드를 볼 때, 서비스 인터페이스와 구현체로 나뉘어 있을 때보다는 서비스 구현체만 있을 때 직관적으로 이해하기 쉬웠기 때문입니다.
위의 경험들을 바탕으로 저는 서비스는 보통 구현체로 먼저 만들고, 필요하다면 추상화를 하는 방식으로 많이 일하는 것 같습니다!
감사합니다.
답변 감사합니다! 자세한 설명 덕분에 쉽게 이해했습니다!