[SOLID][Nest.js][Java + Spring] Interface를 활용한 결합도 분리 (Interface를 이용한 Dependency Injection - DI)

 

 

객체지향의 사실과 오해 : 역할 책임 협력 관점에서 본 객체지향

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."

 

 

GitHub - junyharang-coding-study/GraphQL-Study: GraphQL을 공부하고, 실습한 코드에요 😀

 

 

 

🚀 [Nest.js] Interface를 활용한 결합도 분리

    🔽 Interface를 이용한 Dependency Injection - DI

        📦 개요

SOLID 5 원칙이라는 Object-Oriented Programming, OOP (객체 지향 프로그래밍)의 Software(소프트웨어) Design(디자인)의 다섯 가지 기본 원칙이라는 개념이 있어요. 이 개념의 주요 내용은 시간이 지나도 변경이 용이하고, 유지보수와 확장이 쉬운 소프트웨어 개발이 가능하다라는 것이에요.

그렇기 때문에 객체 지향 프로그래밍에서는 중요한 개념으로 자리 잡고 있어요.

이번 글에서는 SOLID 5원칙 중 주니가 개발할 때, 항상 사용하려고 노력하는 Interface Segregation Principle - ISP (인터페이스 분리 원칙)에 대해 이야기 해보고, 이를 Nest.js에서는 어떻게 구현할 수 있는가? 에 대해 이야기 해보려고 해요.

 

        📦 ISP란?

인터페이스 분리 원칙은 객체는 자신이 호출하지 않는 Method(메서드)에 의존하지 않아야 한다. 라는 원칙이에요.

즉, 구현할 객체에게 무의미한 메서드 구현을 방지하기 위해 반드시 필요한 메서드만을 상속 및 구현하라는 권고 사항이에요.
만약 상속할 객체의 규모가 너무 크다면 해당 객체의 메서드를 작은 단위의 Interface(인터페이스)로 나누는 것도 고려해 봐야 해요.

위 그림을 보면 규모가 큰 객체를 상속했을 때, 발생하는 문제와 이를 인터페이스로 분리하여 해결하는 방법을 나타내 본것이에요.

왼쪽과 오른쪽 객체가 가운데 객체를 각각 상속할 경우 왼쪽 객체는 필요한 메서드가 모두 구현되기 때문에 아무런 문제가 없어요.

하지만, 오른쪽 객체의 경우 Method1을 빼고, 나머지 메서드를 구현할 필요가 없는 상황임에도 불구하고, 가운데 객체를 상속 받았기 때문에 원치 않아도 해당 메서드를 모두 재 정의(Overriding)해 주어야 해요.

만약 상속 대상인 객체의 메서드를 각 동작별로 구분해 인터페이스로 만들었다면 각 객체가 필요한 인터페이스만을 상속하여 구현하면 되기 때문에 각자가 필요한 메서드만을 가지게 될 것이에요.

이것이 바로 인터페이스 분리 원칙의 개념이에요.

이 때, 인터페이스의 장점은 내부 구현을 몰라도 상호 작용을 할 수 있다는 점이에요.

이 말이 무슨 말이냐면 객체 설계 시 외부로 노출되는 인터페이스와 내부에 숨겨진 구현을 명확하게 분리할 수 있다는 의미에요.

이것을 Separation of interface and implementation(인터페이스와 구현의 분리)라고 해요.

또, 안전한 코드를 작성할 수 있어요.
객체 자체를 가져다 사용하는 클래스가 있을 때, 내부가 어떻게 되어 있는지 어떤 메서드가 열려있는지 등을 고려해야해요.

만일 내부 상태를 변경할 수 있는 메서드가 많이 있고, 그걸 잘 못 사용한다면 해당 메서드를 의도치 않게 변경할 수도 있고,
그렇게 되면 다른 곳에서는 사용하는 곳에서는 그걸로 인해 문제가 발생할 수도 있어요.

이를 위해 객체 간의 결합도를 낮춰 유연하고, 안정적인 코드를 작성할 수 있기 위해 인터페이스와 구현체를 분리하는 것이 좋아요.

 

 

 

 

 

 

    🔽 구현하기

        📦 Service Layer

보통 Backend(백엔드)에서 MVC Pattern(패턴)을 이용하여 API를 구현한다면 Controller, Service, Repository로
나누어 개발을 하게 될 거에요.

자프링(Java + Spring Boot) 예시를 한번 볼게요.

EquipmentResolver.java

728x90

위 Resolver(리졸버) Code(코드)를 보면 18번째 줄에 @RequiredArgsConstructor를 선언하고, 22번째 줄에 final Keyword(키워드)를 이용하여 EquipmentService(인터페이스)를 멤버 변수로 선언하고, 사용하는 걸 볼 수 있어요.

EquipmentService.java

EquipmentServiceImpl.java

그리고, ServiceImpl은 Service를 implements 키워드를 이용하여 구현하고,
각 메서드를 @Override 하여 재 정의해주고 있어요.

이는 Spring Boot(스프링 부트) Framework(프레임워크)의 기능이 아닌
순수 자바의 다형성 기능을 이용하여 구현할 수 있어요.

스프링의 의존성 주입 방식은 스프링에서 추상화된 인터페이스를 의존하여도
스프링 Container(컨테이너)가 Runtime(런타임) 시점에 스프링 Bean(빈)에 등록된 구현체를 주입하는 방식이에요.

위 코드에서는 EquipmentService 인터페이스를 만들고,
구현체인 EquipmentServiceImpl을 스프링 빈으로 등록하게 된답니다.

Nest.js 역시 TypeScript에서 이런 다형성을 제공(JavaScript ES6에서는 미지원) 하지만, TypeScript의 경우 Compile(컴파일) 시점에만 인터페이스가 존재하고, 런타임 시점에는 인터페이스가 사라지는 특성과 함께 Nest.js 특성(Module)으로 인해 스프링 부트보단 조금 더 작업할 것이 있어요.

equipment-service.interface.ts

 

equipment-Impl.service.ts

스프링이였다면 여기까지 해주고, Controller에서 이를 주입해서 사용하면 되지만,
Nest.js에서는 그렇게 하면 사용할 수 없어요.

equipment-module.ts

바로 위와 같이 모듈을 등록해주어야 해요.

equipment.resolver.ts

반응형

그리고 Controller에서 위와 같이 생성자에 인자값으로 @Inject("...")를 추가해 줘야 하는데, @Inject()의 인자값은 모듈의 provide 객체의 값을 명시해 주어야 해요.

이를 통해 Provider(프로바이더)를 모듈에 등록할 때, 개발자가 지정한 프로바이더 문자열 Token(토큰)을 주입해주어야 하는 방식이에요.

일반적으로 프로바이더 주입 시 생성자 주입 패턴을 사용하여 프로바이더를 주입하게 되지만, 이 패턴을 사용하려면 Class(클래스)를 의존하고 있어야 하며, 인터페이스를 의존하고 있으면 생성자 주입 패턴을 사용할 수가 없어요.
이는 런타임 시점에 인터페이스가 없기 때문이에요.

이 문제를 해결하기 위해 위와 같이 생성자를 이용해 문자열 토큰 방식으로 프로바이더를 등록하여 의존성 주입을 하고, 주입할 인터페이스 멤버 변수에 @Inject(...)를 달아주어 모듈의 useClass에 명시한 구현체가 주입될 수 있도록 해줘야 해요.

npm run start:dev

구현이 잘 되었나 확인을 위해 서버를 구동하고, PlayGround로 테스트를 진행해 볼게요.

http://localhost:8081/graphql

Console Log

위와 같이 정상 작동하는 걸 확인할 수 있어요.

 

 

클린 코더:단순 기술자에서 진정한 소프트웨어 장인이 되기까지

"이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다."

 

 

 

 

 

🧐 참고 자료

Documentation | NestJS - A progressive Node.js framework

 

NestJS 인터페이스로 DI하기

 

 

DI with Nest.js