NestJS 환경에서 추상 클래스를 구현할 때 implements와 extends 중 무엇을 사용해야 할까?

타입스크립트 관점에서 LogsRepository가 추상 클래스라면 이를 구현하는 클래스는 implements와 extends를 모두 사용할 수있다. implements는 인터페이스 구현체로서의 동작으로 LogsRepository가 정의한 메서드 규격을 모두 지키겠다는 의미를 갖는다.
비슷하지만 조금 다르게 extends는 클래스 상속으로서의 동작으로 LogsRepository의 자식클래스가 되는 의미를 갖고 그 규격을 이어받겠다는 선언이다.

위 링크의 학습정리에서 implements를 사용한 이유는 "추상화된 인터페이스를 구현한다"라는 개념을 강조하기 위함이였다. 하지만 NestJS의 런타임 동작을 고려하면 extends가 권장되는 명확한 이유가 존재한다고 한다.

프로토타입 체인과 Reflection

NestJS의 의존성 주입 시스템은 런타임에 클래스의 인스턴스를 생성하고 관리한다. extends를 사용하면 JavaScript의 '프로토타입 체인' 상단에 LogsRepository가 물리적으로 존재하게 된다. 이는 NestJS 컨테이너가 Reflection(런타임에 코드의 구조, 타입, 메서드를 조사하고 수정할 수 있는 능력)을 사용할 때 결정적인 차이를 만든다. extends를 통해 상속 관계가 명확히 유지되어야만, NestJS는 리플렉션을 통해 "이 객체가 LogsRepository 에 속하는가?"를 런타임에도 정확히 판별할 수 있다.

반면 implements는 타입스크립트 컴파일 시점에만 규격을 체크할 뿐, 변환된 자바스크립트에서는 상속 관계가 완전히 사라져 리플렉션을 통한 타입 추적이 불가능해진다.

런타임 안정성 및 클래스 기반 DI의 이점

NestJS는 providers에서 provide: LogsRepository라고 선언할 때, 이 LogsRepository 클래스 자체를 고유 식별자(Token)로 사용한다. 이때 주입되는 객체가 실제 LogsRepository 타입인지 확인하는 과정에서 extends가 되어 있어야 다음과 같은 이점을 온전히 누릴 수 있다.

• instanceof 검증: 런타임 코드나 테스트 환경에서 instanceof LogsRepository와 같은 검사가 가능해져 타입 안정성이 확보된다. (implements는 false를 반환)

• 다형성 및 로직 상속: 추상 클래스에 정의된 공통 로직이나 일반 메서드를 자식 클래스에서 그대로 물려받아 재사용할 수 있다.

abstract class LogsRepository {
  // 일반 메서드 (로직이 들어있음)
  printHello() {
    console.log("Hello!");
  }
  abstract save(log: string): void;
}

// implements 사용
class InMemoryLogsRepository implements LogsRepository {
  // 에러 발생! LogsRepository에 printHello가 있지만, 
  // implements는 로직을 안 가져오기 때문에 여기서 새로 정의 안 하면 에러가 납니다.
  save(log: string) { ... }
}

// extends 사용
class InMemoryLogsRepository extends LogsRepository {
  save(log: string) {
    this.printHello(); // 부모의 로직을 그대로 물려받아 바로 사용 가능!
  }
}

• 메타데이터 전파: 부모 클래스에 정의된 데코레이터나 메타데이터 정보가 상속 계층을 통해 자식에게 전달되므로, NestJS 프레임워크가 제공하는 다양한 기능을 누락 없이 사용할 수 있다.

Related

• NestJS의 커스텀 프로바이더 선언 (Class Provider)