Interface vs Abstract Class (in Typescript)

객체지향 패러다임에서 빼놓을 수 없는 개념이 바로 인터페이스와 추상 클래스이다.

이들은 모두 각자를 상속할 구현체가 수행할 행동을 추상화하여 명시하고 이를 구체화할 것을 강제한다.

또한 이들만으로는 인스턴스를 생성할 수 없다는 공통점도 존재한다.

결국 특정 인스턴스가 추상화에 의존하게 하여,

결론적으로 객체지향 패러다임의 다형성, 캡슐화라는 공통의 목표를 손쉽게 달성하게 해 준다.

다만 이들 간에는 분명한 차이가 존재하기 때문에

이를 예시를 통해 정리하고자 한다.

 

Interface vs Abstract Class

예시를 위해 위 UML의 관계를 구현하겠다.

Interface 예시

// 인터페이스
interface IHuman {
    spendOneDay(): void;
    work(): string;
}

// 인터페이스 구현
class Student implements IHuman {
    spendOneDay(): void {
        console.log("기상...!");

        console.log(this.work());

        console.log("수면...!");
    }

    work() {
        return "학교에서 공부합니다.";
    }
}

// 인터페이스(추상화)에 타입 의존
const student:IHuman = new Student();
student.spendOneDay();

// 컴파일 에러 발생 
console.log(student instanceof IHuman);

Abstract Class 예시

// 추상 클래스
abstract class Human {
    spendOneDay() {
        console.log("기상...!");

        console.log(this.work());

        console.log("수면...!");
    }

    abstract work(): string;
}

// 추상 클래스에 대한 자식 클래스(구현)
class Student extends Human{
    work() {
        return "학교에서 공부합니다.";
    }
}

// 추상 클래스(추상화)에 타입 의존
const student: Human = new Student();
student.spendOneDay();

// 정상적으로 true 반환
console.log(student instanceof Human);

비교

1. 내부 로직 포함 여부

인터페이스 예시를 들여다보면 인터페이스 내에는 해당 인터페이스가 구현을 강제할 메서드의 이름과 인자, 반환 타입 만이 명시되어있다.

그와 달리 추상 클래스 내에는 인터페이스와 마찬가지인 메서드도 존재하는 반면(abstract 메서드), 실제 로직이 작성된 메서드도 존재한다.

따라서 첫번째 차이는 실제 런타임에서 작동하는 코드가 포함되어 있는지 여부이다.

추상 클래스는 보통 자식 클래스에서 공유할 공통 로직을 부모 추상 클래스에 작성하여

불필요한 코드 재반복 및 향후 수정 소요를 줄이는 방식으로 활용한다.

 

2. 자식 클래스 구현 방식

인터페이스 예시를 보면, Student 클래스가 IHuman 인터페이스에 의존한다는 것을 명시하기 위해 implements를 사용한다. 

반면 추상 클래스 방식에서는 extends를 사용하여 부모 클래스를 상속하게 된다.

여기서 알 수 있는 두번째 차이는 자식 클래스 구현 시 사용하는 implements, extends 여부이다.

implements와 extends에는 차이가 존재하는데,

implements를 통해서는 여러 인터페이스를 동시에 상속할 수 있는 반면 extends를 통해서는 오직 하나의 부모 클래스를 가질 수 있다.

따라서 implements를 사용하는 관계를 has-A 관계,

extends를 사용하는 관계를 is-A 관계라고 한다.

 

3. 런타임에 존재 여부

각 예시의 가장 마지막 라인을 보면 instanceof 를 이용하여 해당 인스턴스가 무엇에서 파생된 인스턴스인지 확인하는 로직이 존재한다.

해당 로직은 추상 클래스 방식에서는 문제없이 작동하지만,

인터페이스 방식에서는 컴파일 에러가 발생한다.

이유는 바로 인터페이스는 컴파일 시 사라지는, 런타임에서 존재하지 않는 코드이기 때문이다.

자바와 같은 언어와 달리, 타입스크립트에서는 인터페이스가 컴파일 타임에만 존재하게 된다. 

따라서 인터페이스를 통한 추상화를 구현한 로직에서 해당 객체가 어떤 인터페이스의 구현체인지 확인하기 위해서는 

타입 가드를 따로 작성해주어야한다.

반면 추상 클래스는 컴파일 시 일반 클래스로 변환되어 런타임에도 존재하기 때문에 instanceof를 통한 간편한 타입 비교가 가능하다.

즉 세번째 차이는 런타임에 코드가 존재하는지에 대한 여부이다.

 

결론

인터페이스와 추상 클래스 모두 타입스크립트 환경에서 추상화에 의존한 로직을 작성할 수 있게 도와주는 도구이다.

이를 잘 활용하면, 향후 세부 요구사항이 추가되더라도 기존 코드를 수정하지 않는 선에서 대처가 가능하다.

기존에 잘 작동하고 있는 코드를 수정하는 것은 항상 에러를 수반하기 때문에 확장성을 고려한 코드를 작성하는 것은 매우 중요하다.

작성된 글을 보면 추상 클래스 방식이 더 이점이 많다고 착각할 수 있지만,

추상 클래스 방식도 결국 부모와 자식 간의 결합도를 높이는 설계이기 때문에

추가 요구 사항에 의해 부모 클래스의 로직이 수정되어야 하는 상황이 왔을 때 유연한 대처가 힘들 수도 있다.

따라서 트레이드오프를 잘 고려하여 적절한 설계를 하는 것이 중요하다.