처음 Spring을 접한 때를 제외하곤, 대부분의 프로젝트를 진행할 때 Service Layer의 코드들을 interface - implements class 형태로 구성을 했었다.
하나의 인터페이스를 구현하는 구현체들이 많다면, 인터페이스와 구현체를 분리하는 것이 적절하다고 생각을 하긴 하지만, 그럴 때가 아니더라도 인터페이스와 구현체를 분리한 적들이 있었다.
이런식으로 말이다.
UserService (Interface) <-> UserServiceImpl (Implemented Class)하지만 가끔 프로젝트를 진행하거나, 개발을 하다보면 너무 관습적으로 인터페이스와 클래스를 분리하여 사용한다는 느낌을 종종 받을 때가 있었다. 뭐, 인터페이스와 구현체를 분리해서 다형성을 지키면서, SOLID 원칙도 생각하면서, 객체 지향적으로 가보자 라는 아주 얄팍한 생각을 탑재한 채로.
그러던 중, ‘제미니의 개발 실무’ 영상중 ‘ServiceImpl 쓰지 말자 feat. interface를 소중히’ 라는 영상을 우연히 마주치고, 이번 기회에 어떤 때에 인터페이스와 구현체로 분리하는 것이 적절할지에 대해서 고민해보며 전보단 확실하게 짚고 넘어가고 싶었다.
https://www.youtube.com/watch?v=8u82cAPQTjc
위 영상에서 본 내용을 우선 정리해보고자 한다. 본론부터 얘기하자면 ‘Interface를 소중히하자‘ 이다.
Interface와 이를 구현하는 구현체가 1대1 관계로만 되어 있을 때, 코드의 양은 무분별하게 2배가 된다.
물론 Inteface가 주는 여러 이점들도 존재하지만, 모든 계층마다 저런 구조로 코드가 구성되어 있다면,,,?
Bottom-Up으로 구성해보자. 우선 개발을 진행하며 하나의 클래스에서 구현을 진행하다, 이 클래스와 공통된 로직이 포함된 다른 클래스가 존재하거나, 많다면 이를 Interface로 추상화하여 구현하는 방식이 적절하다고 한다.
다시 말해, 구현체(클래스)가 하나 밖에 아직 없는데 Interface를 먼저 만들고 시작하는 나 자신을 반성하게 된다.
두번째는, 구현체의 클래스 명을 XXXServiceImpl 이라고 명명하는 관습이다. 이 내용도 처음에 이야기 했던 내용과 일맥상통 한다. Interface를 먼저 정의해놓고 개발하지 않는다면, 구현 클래스의 명을 XXXServiceImpl이라고 명명할 필요가 전혀 없다.
만약, 맨 처음에 UserService가 존재하였고, 그 다음에 NormalUserService라는 클래스가 탄생하고, 그 다음에 또 HeavyUserService가 탄생하게 되면, 이때 3개의 클래스에 공통된 부분이 있거나 혹은 형태가 어느정도 일치하다고 판단이 되면, Interface로 추상화를 이때 진행해도 좋을 것 같다.
이때 영상에서는 Interface의 명을 UserService라고 꼭 명명할 필요가 없다고 했다. UserRegister가 됐든, UserManaging이 됐든… 암튼 너무 관습적인 것들을 그대로 따를 필요가 없다는 것을 말하고 싶었던 것 같다.
인터페이스는 추상화를 통해 의존성을 끊어주는 것을 목적으로서 사용되어야 하고, 또 이 의존성을 줄여주는 것이 가치가 있으려면 구현체가 여러개가 존재해야 하는 상황이어야 하기 때문이다.
