[Spring] Service, ServiceImpl 의 관계 (feat. OCP)

문제 인지

회사에서 개발중인 spring boot 프로젝트 구조를 보면서 Service layer 의 impl 폴더와 interface 가 눈에 계속 밟혔습니다. 본디 자바에서 인터페이스를 사용하는 이유는 객체지향 특징 중 하나인 다형성 입니다.

 

다형성: 하나의 자료형에 여러가지 객체를 대입하여 다양한 결과를 얻어내는 성질

 

그런데 위의 그림을 보면 하나의 자료형(Interface ICSA2010Service)에 대하여 여러가지 객체가 존재하나요? 아닙니다. 해당 인터페이스의 구현체는 impl 패키지 하위에 하나 밖에 존재하지 않습니다. 즉 1:N 관계가 아닌 1:1의 관계를 형성하면서 인터페이스를 사용중인 것이죠. 

 

 

OCP 에 입각한 코드이긴 하나,, 의도를 알고 쓰는 것인가?

 

사실 이게 잘못 된 것은 아닙니다. OCP 원칙에 입각하여 인터페이스와 구현체를 분리하면, 특정 기술을 추가하거나 변경하더라도, 클라이언트 코드(호출 영역)는 수정하지 않아도 됩니다. 물론 인터페이스와 구현체가 1 : N 관계 일 때 해당하는 말이죠. 

 

 

하지만 실제로 대부분의 프로젝트의 코드를 보면, interface 와 구현체 클래스는 1:1로 구성되어, 실질적으로 인터페이스를 갈아끼우는 상황이 그다지 존재하지 않습니다. 대부분의 프로젝트, 당장 회사 프로젝트에서도 관습적으로 인터페이스와 구현체를 생성하는 것은 아닌가 생각이 들었습니다. 

 

관습적인 추상화의 장점과 단점

인터페이스와 구현체를 분리하여 얻을 수 있는 장점은 구현체 클래스를 변경하거나 확장하더라도, 이를 호출하는 클라이언트 코드에는 영향을 주지 않는다는 점입니다.

 

좀 더 자세히 설명해보겠습니다.

클라이언트 코드를 호출부라 부른다면, Service Layer 입장에서는 서비스 클래스를 호출하는 컨트롤러 클래스가 클라이언트 코드일 수 있습니다. Service layer 의 구현체 클래스를 변경하거나 교체했다고 가정해보겠습니다. (ex, AServiceImpl -> BServiceImpl)

클라이언트인 컨트롤러 입장에서는 어차피 의존주입하는 타입은 IService 라는 인터페이스고, 여기에 정의된 추상 메서드는 변하지 않습니다.

 

인터페이스

// Interface

public interface IService {

    String test();

}

 

구현체

@Service
public class AServiceImpl implements IService {

    @Override
    public String test() {
        return "AServiceImpl";
    }

}

 

컨트롤러

// Controller 

@RequiredArgsConstructor
@RestController
public class SampleController {

    private final IService service;

    @GetMapping("/test")
    public String test(){
        return service.test();
    }

}

 

위 예시 코드를 보면 컨트롤러는 특정 구현체가 아닌 IService 타입을 의존 주입받고 있습니다. (물론 특정 구현체인 AServiceImpl 을 의존주입 받아도 괜찮습니다.)

이렇게 구현체가 아닌 인터페이스를 의존받으면 OCP 원칙을 지킬 수 있습니다. 무슨 뜻인지 잘 모르겠다면 임의로 BServiceImpl 구현체를 추가해보겠습니다.

 

 

또 다른 구현체 (BServiceImpl)

public class BServiceImpl implements IService {

    @Override
    public String test() {
        return "BServiceImpl";
    }

}

AServiceImpl 와 마찬가지로 IService에 선언된 test() 메서드를 구현하고 있습니다. 이제 이 클래스에 @Service 어노테이션을 붙이면 스프링 컨테이너에 의해 SampleController 로 의존주입이 됩니다. ( AServiceImpl 의 @Service 어노테이션은 제거해주어야 합니다.)

 

느낌이 오시나요? 

IService 라는 인터페이스를 구체화 하는 구현체간의(AServiceImpl, BServiceImpl) 차이만 있을 뿐, 클라이언트 코드(컨트롤러) 입장에서는 무엇이 변했는지 전혀 모르는 상태입니다. 여기서 모르는 상태라는 것은, ServiceLayer 의 구현체가 변경되더라도 클라이언트 코드는 전혀 수정할 필요가 없다는 의미입니다. 지금은 단순히 test() 라는 메서드에서 문자열을 출력하는 기능밖에 없어 감흥이 없을 수 있습니다. 유명한 예제인 정률 할일(%할인) 정액 할인(1000원 할인) 을 생각해봅시다. 만약 현재는 정률 할인을 진행하더라도, 갑자기 정액할인으로 정책이 변경된다면, 위의 예제처럼 서비스레이어의 어노테이션만 바꿔주면 간단하게 변경된 정책을 코드상 배포할 수 있게 됩니다. 

 

↔ 만약 인터페이스와 구현체가 분리되어 있지 않다면?

이 포스팅을 쓰게 된 계기는 보통 인터페이스와 구현체간의 관계가 1:N 이 아닌 1: 1 관계이기 때문입니다. 구현체가 2개 이상이 아니라면 인터페이스가 필요없지 않을까요? 굳이 인터페이스 없이 서비스 코드만 존재해도 괜찮지 않을까요?

어느정도는 그렇다고 생각하지만, 그럼에도 여전히 인터페이스를 굳이 선언하고 구현체 코드를 생성할 것 같습니다. 이유는 기획 정책에 유연하게 대응하고 싶기 때문입니다. "아무리 봐도 이 API 는 기획 정책이 변경될 일이 없을꺼야" 라고 단언할 수 있다면 인터페이스를 만들지 않겠지만, 짧은 경험으로나마 기획 정책은 얼마든지 변경될 수 있다고 느끼게 됐습니다. 또한 위의 예시 코드를 통해 OCP 를 지킬 때 가질 수 있는 편리함과 안정성 역시 놓칠 수 없는 부분이라고 생각합니다.

 

 

 

네이밍 컨벤션은 이대로 괜찮은가(feat. impl, I)

추가적으로 다른 포스팅을 통해 인터페이스의 네이밍 컨벤션에 대해서도 생각해 볼 수 있었습니다.

Impl 을 구현체에 붙이는것이 관습적인 네이밍 컨벤션이 됐지만 이것이 타당한지 고민해볼 필요가 있습니다.

대표적으로 자바 Collection 의 List 인터페이스를 구현한 ArrayList, LinkedList 에서는 impl 이라는 접미사는 찾아볼 수 없습니다.

아래는 스택오버플로우 에서 발췌한 구문입니다.

Look to the Java standard library itself. Do you see IList, ArrayListImpl, LinkedListImpl? No, you see List and ArrayList, and LinkedList. Here is a nice article about this exact question. Any of these silly prefix/suffix naming conventions all violate the DRY principle as well.

 impl 을 접미사로 붙이는 것이 DRY 원칙을 위배하며 불필요한 네이밍 컨벤션이라고 신랄하게 비판하고 있습니다. 위 글을 읽고 나니

앞으로 interface 의 구현체를 만들때 네이밍을 어떻게 해야할지 다시금 생각하게 됐습니다.

현재 회사의 프로젝트부터 이런식의 네이밍 컨벤션을 바꾸고 싶지만, 이미 관습으로 굳어진 사항을 개인이 바꾸려고 하는 것은 다소 무리가 있다고 봅니다. 앞으로의 개인 프로젝트부턴 이런 사항에 대해 인지하면서 네이밍을 신경써야겠습니다.

 

 

reference

https://see-one.tistory.com/1

https://stackoverflow.com/questions/2814805/java-interfaces-implementation-naming-convention