인터페이스를 활용한 설계

데이터를 처리하는 클래스가 진행 상황을 기록해야 한다고 해 봅시다. 처리 클래스 안에서 콘솔에 기록하는 클래스를 직접 만들면, 나중에 파일에 기록하거나 테스트에서 기록을 모아 확인하고 싶을 때마다 처리 클래스를 고쳐야 합니다. 기록하는 방법이 바뀌었을 뿐인데, 데이터를 처리하는 코드까지 함께 바뀌는 것입니다.

이 글은 처리 클래스가 필요한 기능을 인터페이스로 정하고, 실제로 기록하는 객체는 바깥에서 넘겨받게 바꾸어 이 문제를 풉니다. 그 과정에서 다형성과 개방-폐쇄 원칙, 의존성 역전 원칙이 무엇을 뜻하는지 확인하고, 테스트에서 쓰는 메모리 대역으로 호출 순서를 검사합니다. 예제는 ts-first 프로젝트에 design.ts를 만들고 include를 그 파일로 바꾸어 확인합니다.

필요한 기능을 인터페이스로 정하기

먼저 처리 클래스가 기록 기능에서 무엇을 필요로 하는지를 Logger 인터페이스로 적습니다. 그다음 이 모양을 갖춘 클래스를 여러 개 만들고, 처리 클래스는 구체적인 클래스가 아니라 Logger 타입의 객체를 생성자로 받습니다.

interface Logger {
  log(message: string): void;
  warn(message: string): void;
  error(message: string): void;
}

class ConsoleLogger implements Logger {
  log(message: string): void {
    console.log(`[INFO] ${message}`);
  }
  warn(message: string): void {
    console.log(`[WARN] ${message}`);
  }
  error(message: string): void {
    console.log(`[ERROR] ${message}`);
  }
}

class FileLogger implements Logger {
  constructor(private fileName: string) {}

  log(message: string): void {
    console.log(`[FILE ${this.fileName}] INFO ${message}`);
  }
  warn(message: string): void {
    console.log(`[FILE ${this.fileName}] WARN ${message}`);
  }
  error(message: string): void {
    console.log(`[FILE ${this.fileName}] ERROR ${message}`);
  }
}

class DataProcessor {
  constructor(private logger: Logger) {}

  processData(): void {
    this.logger.log("데이터 처리 시작...");
    this.logger.warn("임시 파일 생성됨.");
    this.logger.log("데이터 처리 완료.");
  }
}

new DataProcessor(new ConsoleLogger()).processData();
new DataProcessor(new FileLogger("app.log")).processData();

[INFO] 데이터 처리 시작...
[WARN] 임시 파일 생성됨.
[INFO] 데이터 처리 완료.
[FILE app.log] INFO 데이터 처리 시작...
[FILE app.log] WARN 임시 파일 생성됨.
[FILE app.log] INFO 데이터 처리 완료.

DataProcessor의 코드는 한 글자도 바꾸지 않았는데, 넘겨준 객체에 따라 기록의 모양이 달라졌습니다. 이 예제의 FileLogger는 실제로 파일을 쓰지 않고 파일 이름을 붙여 출력만 하며, 실제 프로그램이라면 경고와 오류는 console.warn이나 console.error로 표준 오류에 보내기도 합니다. 여기서는 출력의 순서를 한 흐름으로 보기 위해 모두 console.log로 적었습니다.

Logger 인터페이스가 정하는 것은 메서드의 이름과 타입뿐입니다. 본문이 비어 있는 log 메서드도 이 모양을 갖추므로, 기록이 정말 남는지와 언제 예외를 던지는지 같은 동작은 구현과 테스트로 따로 확인해야 합니다.

위 그림의 위쪽은 정적인 타입의 관계로, DataProcessor는 Logger 타입에 의존하고 여러 구현 클래스가 그 모양을 갖춥니다. 아래쪽은 실행 중에 일어나는 일로, 초기화 코드가 실제 객체를 만들어 생성자에 넘기고 DataProcessor가 그 객체의 메서드를 부릅니다. 인터페이스는 컴파일한 뒤 지워지므로, 실행 중에는 인터페이스가 아니라 그 모양을 갖춘 실제 객체가 오갑니다. 그림의 메모리 대역은 이 글의 뒤에서 만듭니다.

다형성과 개방-폐쇄 원칙

DataProcessor의 this.logger는 어떤 때는 ConsoleLogger이고 어떤 때는 FileLogger이지만, DataProcessor는 그 차이를 모른 채 같은 메서드를 부릅니다. 앞의 글들에서 본 다형성이 클래스의 상속이 아니라 인터페이스로 이루어진 것입니다.

새로운 기록 방법이 필요해지면 Logger를 구현하는 클래스를 하나 더 만들면 되고, DataProcessor는 고치지 않아도 됩니다. 기능을 더할 때는 새 코드를 추가하고, 이미 잘 동작하는 코드는 고치지 않게 만드는 이 성질을 개방-폐쇄 원칙(open-closed principle)이라고 합니다. 다만 어떤 구현을 만들어 넘길지 정하는 초기화 코드는 바뀌어야 하고, Logger 인터페이스 자체가 바뀌면 DataProcessor도 영향을 받는다는 점은 남습니다.

의존성 역전 원칙

의존성 역전 원칙(dependency inversion principle)은 두 문장으로 요약됩니다. 첫째, 상위 모듈은 하위 모듈에 의존하지 않고 둘 다 추상에 의존해야 합니다. 둘째, 추상은 세부 구현에 의존하지 않고, 세부 구현이 추상에 의존해야 합니다.

이 글의 예제에서 상위 모듈은 기록이라는 기능을 쓰는 DataProcessor이고, 하위 모듈은 기록을 실제로 하는 ConsoleLogger와 FileLogger이며, 추상은 Logger 인터페이스입니다. 처음처럼 DataProcessor가 ConsoleLogger를 직접 만들면 상위 모듈이 하위 모듈에 의존하지만, 지금은 DataProcessor도 두 구현 클래스도 모두 Logger를 바라봅니다.

"역전"이라는 이름은 Logger를 누가 정하느냐에서 나옵니다. Logger는 기록 기능을 쓰는 DataProcessor가 필요로 하는 모양으로 정해지고, 구현 클래스들이 그 모양에 맞추어 만들어집니다. 그래서 의존의 방향이 "상위가 하위의 구체적인 클래스를 안다"에서 "하위가 상위가 정한 모양을 따른다"로 뒤집힙니다.

메모리 대역으로 호출 검사하기

인터페이스로 의존을 끊어 두면, 테스트에서는 실제 기록 대신 기록을 배열에 모으는 대역(test double)을 넘길 수 있습니다. 앞의 코드에 이어서 다음을 붙여 실행합니다.

class MemoryLogger implements Logger {
  readonly entries: string[] = [];

  log(message: string): void {
    this.entries.push(`INFO: ${message}`);
  }
  warn(message: string): void {
    this.entries.push(`WARN: ${message}`);
  }
  error(message: string): void {
    this.entries.push(`ERROR: ${message}`);
  }
}

const memoryLogger = new MemoryLogger();
new DataProcessor(memoryLogger).processData();
console.log(memoryLogger.entries.length);
console.log(memoryLogger.entries.join(" | "));

3
INFO: 데이터 처리 시작... | WARN: 임시 파일 생성됨. | INFO: 데이터 처리 완료.

processData는 log, warn, log의 순서로 부르고, MemoryLogger는 그 순서대로 배열에 기록을 더하므로 기록은 세 개입니다. 파일이나 콘솔 없이도 어떤 메시지가 어떤 순서로 남았는지 확인할 수 있어서, 테스트가 빠르고 결과가 늘 같습니다. entries의 readonly는 다른 배열을 다시 넣는 것만 막고 push는 막지 않으며, 이 검사 하나로 파일 쓰기나 실패할 때의 경로까지 확인한 것은 아닙니다.

인터페이스를 쓰는 곳은 이 밖에도 많습니다. 같은 문제를 푸는 여러 알고리즘을 바꾸어 끼우는 전략 패턴(strategy pattern), 상태의 변화를 여러 구독자에게 알리는 옵저버 패턴(observer pattern), 외부에서 만든 기능을 정해진 모양으로 붙이는 플러그인 구조가 모두 같은 원리를 씁니다. 이런 설계는 SOLID 원칙 적용과 의존성 주입과 IoC 컨테이너에서 더 자세히 다룹니다.

인터페이스 확장 복습

2장에서 본 것처럼 인터페이스는 extends로 다른 인터페이스를 확장할 수 있고, 클래스는 확장된 인터페이스의 모든 멤버를 구현해야 합니다. 다음 코드는 정리 기능 하나만 가진 작은 인터페이스 Cleanable과, 그것을 확장한 RunnableProcess를 클래스 하나가 구현하는 예입니다. 구현해야 할 멤버가 하나라도 빠지면 실행하기 전에 class 선언에서 진단됩니다.

interface Cleanable {
  dispose(): void;
}

interface RunnableProcess extends Cleanable {
  isRunning: boolean;
  run(): void;
}

class BackgroundTask implements RunnableProcess {
  isRunning = false;

  run(): void {
    console.log("백그라운드 작업 시작...");
    this.isRunning = true;
  }

  dispose(): void {
    console.log("백그라운드 작업 자원 해제.");
    this.isRunning = false;
  }
}

const task = new BackgroundTask();
task.run();
task.dispose();

백그라운드 작업 시작...
백그라운드 작업 자원 해제.

RunnableProcess는 Cleanable의 dispose를 물려받고 isRunning과 run을 더하므로, BackgroundTask는 세 멤버를 모두 갖추어야 합니다. 작은 인터페이스를 여럿 두고 필요한 만큼 확장해 조합하면, 어떤 코드는 Cleanable만, 어떤 코드는 RunnableProcess 전체를 요구하도록 의존하는 범위를 좁힐 수 있습니다. 이 클래스는 메시지를 출력하고 isRunning을 바꿀 뿐, 실제 운영체제의 작업이나 자원을 다루지는 않는 학습용 예제입니다.

정리

• 기능을 쓰는 클래스가 필요한 모양을 인터페이스로 정하고 구현 객체를 생성자로 넘겨받으면, 그 클래스를 고치지 않고 구현을 바꾸어 끼울 수 있습니다.
• 인터페이스는 메서드의 이름과 타입만 정하므로, 구현이 실제로 올바르게 동작하는지는 테스트로 따로 확인합니다.
• 새 기능을 새 구현의 추가로 해결하고 기존 코드는 고치지 않게 하는 성질이 개방-폐쇄 원칙입니다.
• 의존성 역전 원칙에서는 상위 모듈과 하위 모듈이 모두 상위 모듈이 필요로 하는 추상에 의존하며, 하위 모듈이 그 모양을 따릅니다.
• 같은 인터페이스를 구현한 메모리 대역을 넘기면, 파일이나 콘솔 없이 호출의 순서와 내용을 검사할 수 있습니다.

연습 문제

1. 같은 대역을 두 번 쓰기

위의 memoryLogger를 그대로 두고 new DataProcessor(memoryLogger).processData();를 한 번 더 실행하면, entries에는 기록이 몇 개 있고 어떤 순서인가요?

2. 쓰지 않는 메서드 지우기

지금의 processData는 error를 부르지 않습니다. 그렇다면 MemoryLogger에서 error 메서드를 지워도 검사를 통과하나요?

3. 작업 상태의 변화

BackgroundTask의 isRunning을 만든 직후, run()을 부른 직후, dispose()를 부른 직후에 각각 읽으면 어떤 값인가요?

이것으로 4장의 클래스와 인터페이스를 마칩니다. 다음 장의 타입 가드와 타입 좁히기에서는 지금까지 여러 번 쓴 typeof와 in 같은 좁히기를 정리하고, 직접 타입 가드 함수를 만드는 방법을 다룹니다.