왜 Impl는 사용하지 말라는 걸까?

??? : 일단 동작하게 만들어봐

🤔 Impl ? 

Impl 사용 예시

• 변동사항에 쉽게 적용하기 위해 사용되는 인터페이스/구현체 방식에서 자주 사용되는 구현체 이름이다.
• Service를 인터페이스로 구현하고, 해당 Service의 실제 구현체를 `ServiceImpl`라는 명칭으로 주로 사용한다.

실제로 위 사진처럼, 나는 프로젝트 대부분의 Service를 위와 같이 구현하고 있었다.

 

🎯 Impl를 사용했던 이유

스프링을 처음 배울때부터 Service단의 미래에 발생할 확장을 위해 작성한다고 배웠고, 실제로 DB로 변경하거나 특정 조건에 따라 각기 다른 서비스를 제공해야 하는 경우에서 유용하게 사용되는 것을 보았다.

 

그래서 프로젝트 기획에서 확장에 관하여 정해진 것이 없었지만, 미래에 있을 확장을 위해 미리 인터페이스/구현체 방식으로 구현했다. 

 

😨 Impl을 사용하지 말라는데 ?

어느 날, 팀원들과 함께 코드를 보던 중 이런 피드백과 관련 영상을 받았다.

관련 영상 ( 제미니의 개발실무 )

 

영상을 통해 이해한 것을 정리해 보면,

1. 인터페이스도 자원이므로, 아껴서 사용해야 한다.
2. 인터페이스가 가져다주는 이점이 당연히 많지만, 인터페이스가 많으면 많을수록 직관력이 떨어진다.
3. 남발하는 것은 좋지 않다고 생각하기 때문에, 정말 써야 하는 경우에만 쓰는 것이 좋다.

해당 영상을 보면서 든 나의 생각은 

1. 확장성이 명확하지 않은 상태에서 무작정 Impl를 사용하는 것은 좋지 않구나.
2. 하지만 개발초기에 확장성이 정해지는 serivce가 얼마나 있을까?

 

사실 위 코드를 작성하면서도 "무작정 Impl로 구현하는 것이 맞는가?"라는 의구심이 들었지만,

확장성을 배제하고 작성하기에는 마음에 걸렸다.

🙋‍♂️ 현업자분들의 생각

 

그래서 해당 고민을 현업자분에게 여쭤보았고, 정리해 보면 다음과 같다.

1. 레거시 코드(Legacy Code)로 인해 어쩔 수 없이 따라야 하는 경우가 존재한다.
2. 하지만 개발 초기라면, 무작정 Impl를 구현하진 않을 것 같다.
3. 초기에 확장성이 정해지는 경우가 드물며, 그런 경우를 제와하면 우선 구현에만 집중할 것 같다.
4. 하지만 Impl로 구현을 시작하는 것은 잘못된 방식이 아니니, 개발 환경 및 스타일에 따라 다를 것 같다.

💡 참고사항 
JPA와 QueryDSL을 사용해서 인터페이스를 확정해야 할 때는 Impl를 써야 스프링이 인식을 할 수가 있다.

 

💁‍♂️ 사실 핵심은...

사실 핵심은 "Service / Impl 구조를 사용하지 말라"가 아니라 "Impl라는 이름을 사용하지 말라"였다.

 

영상 뒤편에도 나오고, 현업자분들도 아래와 같은 의견에 모두 동의하셨다.

 

1. Impl는 단순 "구현체"라는 의미가 가지고 있기 때문에 단순하고 모호하다.
2. Service라는 명칭에 너무 얽매이지 않아도 된다.
3. 더 자세하게 명칭을 정하자. (ex. UserRegister, UserManager...)

 

📚 정리

확장 측면에서 인터페이스가 가져다주는 이점은 많다.

 

그러나 확장성이 정해지지 않은 상태에서 무작정 `Impl`로 구현하는 것은 직관련을 떨어트리는 것 같다.

 

그래서 웬만하면

 

`Interface UserSerivce` 구현 이후 `class UserServiceImpl`를 구현하는 것이 아닌,

`class UserServiceImpl`구현 이후 추후에 확장성이 확정되면 `Interface UserSerivce`를 구현하여 인터페이스의 이점을 보자.

 

그리고 `Impl`보다는 더 자세하고 듯을 확실히 전달할 수 있는 명칭을 사용하자.