프로젝트를 진행하다보면 Service는 Interface 로 만들고 구현은 ServiceImpl에 하는 것을 본적이 있을것이다. 왜 굳이 바로 구현을 하지 않고 다른곳에 구현을 하는 것일까?
결론부터 말하자면 이는 객체지향의 설계 5 원칙중 하나인 OCP를 실현하기 위해서이다
▶ 그럼 OCP 란 무엇일까?
간단하게 말해보자면 개방-폐쇄 원칙으로써 확장에 대해 열려있고 수정에는 닫혀 있어야한다는 뜻으로 개발 작업을 하다보면 수많은 모듈이 생성된다. 근데 그 하나의 모듈이 완벽할수 있을까? 혹여 완벽하다 하더라도 수정을 피하기는 어렵다하지만 수정을 하다보면 연관되어 있는 모든 모듈을 줄줄이 고쳐야 한다면 그것이 좋은 개발이라고 할 수 있을까?
이에 개발 - 폐쇄 원칙에 따라 시스템의 구조를 올바르게 리펙토링하여 나중에 이와 같은 유형의 변경이 더 이상의 수정을 유발하지 않게 하는것이다. 이 원칙을 잘 사용한다면 기능을 추가하거나 변경이 진행될때 이미 작동중인 코드는 변경하지 않아도 전혀 영향이 없는것이다.
그래서 우리는 Service 를 Interface 화 하여 모든 메소드를 추상화하고 ServiceImpl에서 추상화된 메소드를 구현함으로써 다른 모듈은 추상화된 Service 를 의존하고 수정에 닫히게 되고 반대로 추가하는 것으로 새로운 클래스를 만들어 확장또한 굉장히 간단하다. 따라서 추상화와 OCP 는 뗄래야 뗄 수 없는 관계이다.
▶ Service 예시
다시 Service 의 얘기로 돌아와 만드는 과정 그리고 어떻게 사용되는지 확인해 볼수 있다.
1. Service Interface 생성
public interface MainService {
String doFilter();
}
이렇게 만들게 되면 다른곳에서 추상화 메소드인 doFilter 를 Service 를 받아서 사용할 수 있는데
2. Service 를 가져온 ServiceImplA 생성
public class MainServiceImplA implements MainService {
@Override
public String doFilter() {
return "A 입니다";
}
}
3. Service 를 가져온 ServiceImplB 생성
public class MainServiceImplB implements MainService {
@Override
public String doFilter() {
return "B 입니다";
}
}
이렇게 두개를 사용할 수 있다는 것이다. 그럼 우리가 Service 의 doFilter 의 내용이 바뀔때마다 작성하는것이 아닌 구현체에만 와서 바꿔주면 다른곳에서도 충분히 바꿔줄수 있는것이다.
근데 잘 생각해보면 뭔가 이상하다. 우리가 프로젝트를 만들면 대부분 인터페이스와 구현체는 1:1 관계로 묶이게 되는데 굳이 이렇게까지 만들어야 할 필요가 있을까?
▶ 관습적인 추상화가 계속 되야 하는걸까?
개발은 정답보다는 더 나은 방법이 있다고 생각한다. 사실 서비스가 돌아가기만 하면 장땡인 마인드로 만든다면 interface화 하던 안하던 무슨 상관인가? 하지만 지금까지 개발자들은 그것을 허락하지 않았다 귀찮은 중복 코드는 최대한 줄였고 서로에게 간섭이 강하게 연결된 모듈은 최대한 약하게 하는 결합도의 수준또한 만들어 두었다 이처럼 우리는 더 좋은 코드를 만들어 나가기 위해 노력해왔고 Service 도 이에 나타난 효과같은것이다.
만약 지금 당장은 필요없을수 있다. 하지만 우리의 서비스는 점점 깊어지고 그에 따른 코드또한 길어지고 복잡해질 것이다. 코드는 나만 보는것이 아닌 같이 일하는 사람들이 보는 것이고 남들이 보기에 조금이라도 더 편하게 하기 위해 만들어지는 것이 좋다고 생각한다.
따라서 우리가 이렇게 구분을 지어놓고 개발을 진행하는건 앞으로 더욱 커질 서비스를 대비하며 더 나아가 같이 일할 협업자들에게도 꼭 필요한 일이 될 것이다.
https://wildeveloperetrain.tistory.com/49
관습적인 추상화 Service, ServiceImpl 구조를 사용해야 할까?
Service interface와 ServiceImpl class 구조를 사용하는 이유? 대부분의 프로젝트는 Service를 만들 때 MemberService와 같이 서비스를 인터페이스로 설계하고, MemberServiceImpl 라는 구현체인 클래스를 생성해서
wildeveloperetrain.tistory.com
'Spring > 🌲 Spring' 카테고리의 다른 글
🌲 Spring 의 @Scheduling (1) | 2024.04.20 |
---|---|
🌲 Entity 와 DTO 의 차이 (0) | 2023.08.03 |
🌲 @NoArgsConstructor 와 @AllArgsConstructor 그리고 @RequiredArgsConstructor (0) | 2023.08.03 |
🌲 RestController 와 Controller 의 차이 (0) | 2023.08.03 |
🌲 Request 와 Response (0) | 2023.08.03 |