[개발] 🤦🏻‍♀️고민하기 - Service/ServiceImpl 사용에 대한

🛤️상황

핑크색 폴더의 내용이 내가 작성한 것이고, 노란색 폴더의 내용이 팀원이 작성한 것이다.

나는 ReviewService - ReviewServiceImpl의 구조를 취했고, 팀원은 Impl 클래스를 없애고 거기에 있는 구현 코드를 controller에 작성하였다.  팀원이 그렇게 작성한 이유는

1. JPA를 사용하기 때문에 내가 직접 구현해야 하는 메서드들이 적다.
2. service - impl 구조를 취하지 않는 것이 더 편리하다고 생각다.
3. 지금 우리 프로젝트의 기능들이 그렇게 복잡한 구조를 요구하지 않는다.

하지만 나는 service - impl 구조로 프로젝트를 진행하고 싶었다. 그 이유는 다음과 같다.

1. 그게 가장 노멀하고 정석적인 방법이라고 생각했다.
2. 지금까지 공부한 책,블로그,강의 등에서 대부분은 그렇게 해왔다.
3. 정석의 방식을 따르는게 나중에 탈이 없을 것이라고 생각했다.

---

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

🎢과정

팀원은 좀처럼 의견을 굽히지 않았다... 완고하게 No Impl 구조를 고집했고, 나는 그게 잘 이해되지 않았다.😅  나는 팀원을 설득하고자 장문의 카톡을 2번이나 보냈지만 무용지물!! 그러다가 팀원이 나를 설득하기 위해 본인의 생각과 유사한 블로그들을 보내기 시작했다. 블로그에 있는 내용을 읽어보니 설득이 되지 않고는 배길 수 없었다.

•  '인터페이스 - 구현체 구조로 코드를 작성한다면 그 목적을 알고 목적에 맞게 작성하는 것이 바람직할 것이다.'  ▶️ 블로그에서 이야기했는데 사실 목적을 명확히 알고 작성했다기보다는 그게 좋다는 이야기를 들었으니까 막연하게 한 느낌이 없지 않기 때문이다.
• '개방 폐쇄 원칙(OCP)에 기반한 전략 패턴을 미리 설계한 것이 아닌 그저 습관적인 사용이라면 전혀 무의미하다는 것입니다.'  ▶️ 전략 패턴을 미리 설계했을리가 만무하다... 우리 팀의 실력이 갈수록 좋아지기는 하겠지만 그걸 설계를 하고 들어갈 생각도 못했고, 그걸 설계를 하고 나중에 가서도 변경이 필요가 없을 만큼 설계를 하는 것도 불가능했을 것이다.ㅠㅠ
• 결론적으로 지금 당장 그 원칙을 지켜서 얻는 이점이 없었고, 블로그에서 쓴 글처럼 Service에 있는 메소드를 완전히 픽스시켜놓고 구현체(Impl)만 변경하면 되는 단계까지 올라간 것도 아니기 때문에 그 OCP 방식의 이점을 얻은 점도 현재로선 거의 얻은 게 없다. 

---

🗝️결론

일단 No Impl 체제로 가기로 했다...ㅎㅎ 나중에 우리 프로젝트가 많이 커지거나 복잡한 구조의 기능들을 제공하지 않는다면 큰 문제는 없을 거 같지만........나중에 어떻게 진행될지 모르기 때문에 아직도 걱정이 되기는 한다...

 

 

https://colabear754.tistory.com/109

[Spring/Spring Boot] Service와 ServiceImpl 구조에 대하여

https://velog.io/@osk3856/di-and-interface

<퍼온 글>ServiceImpl, Service 을 왜 사용해?

⬆️ 위에 있는 블로그들이 팀원이 나에게 보내준 블로그들이다.