Interface in TS (vs Java)

타입스크립트의 인터페이스와 자바의 인터페이스는 서로 유사한 구조와 목표를 갖지만,

이용 방식과 더불어 언어적 차이에서 오는 작동 방식에서 차이가 존재하여 이를 정리하고자 한다.

 

Interface란?

출처: https://coding-factory.tistory.com/867

인터페이스는 객체지향 패러다임에서 로직을 구성할 때 추상화에 의존할 수 있게 해주어

결과적으로 캡슐화, 다형성을 달성하기 쉽게 해주는 도구이다.

구체적으로,

인터페이스는 이를 구체화할 객체가 가져야 할 메서드(행동)의 타입 정보를 명시하는 역할을 한다.

실제 구현은 포함시키지 않으며, 코드 상에서도 실제 구현체를 직접 의존하는 것이 아닌 추상화 인터페이스를 의존하게 로직을 작성하여

의존하는 객체로 하여금 해당 객체의 세부 구현을 알지 못해도 협력이 가능하도록 돕는다.(캡슐화)

인터페이스와 인터페이스의 구현체의 관계를 has-A 관계라고 하는데,

이는 특정 구현체가 동시에 다양한 인터페이스를 상속할 수 있음을 내포한다.

 

TS vs Java

컴파일 타임의 타입 검사 방식

// Typescript
interface Human {
  name: string;
  job: string;
  
  setInfo(name: string, job: string): void;
  introduce(): string;
}

// Java
interface Human {
  int MAX_AGE = 100;
  
  void setInfo(String name, String job);
  String introduce();
}

타입스크립트와 자바에서 인터페이스를 선언하는 방식은 위와 같다.

둘은 모두 Human 인터페이스를 구현할 객체가 가져야 할 메서드를 명시적으로 선언하고 있다.

위 코드를 통해 알 수 있는 차이점은, 

타입스크립트에서는 인터페이스에서 외부로 노출할 프로퍼티에 대한 설정도 가능한 반면, 자바에서는 불가능하다는 점과

타입스크립트에서는 인터페이스 내에서 인터페이스의 상수를 선언할 수 없지만, 자바에서는 상수 선언이 가능하다는 점이다.

(선언이 단순 int로 되어 있지만 컴파일 단계에서 저절로 static final이 추가되어 상수가 된다.)

 

또한 위 코드 상에서는 확인할 수 없는 차이점도 존재한다.

첫번째는 바로 컴파일 시 타입 검사를 수행하는 방식의 차이이다.

결론부터 말하자면

타입스크립트는 구조적 타이핑(Structural Typing) 방식으로 검사를 수행하는 반면,

자바는 명목적 타이핑(Nominal Typing) 방식으로 검사를 수행한다.

먼저 타입스크립트의 경우이다.

// Typescript
interface IHuman {
    name: string;
    job: string;

    setInfo(name: string, job: string):void;
    introduce(): string;
}

class Student {
    name: string = "";
    job: string = "";

    setInfo(name: string, job: string) {
        this.name = name;
        this.job = job;
    }
    introduce() {
        return `my name is ${this.name} and my job is ${this.job}`;
    }
}

// Student가 직접적으로 IHuman을 상속하지 않았음에도 타입 바인딩에 문제 x
const student: IHuman = new Student();
student.setInfo("Luka", "developer");
console.log(student.introduce());

앞서 보인 Human 인터페이스와

이를 직접적으로 상속(implements)하지는 않았지만 그에 맞게 내부 구현을 구성한 Student 클래스가 있다.

이 때 재밌는 것은 코드 하단의 student 변수의 클래스인 Student가 IHuman 인터페이스를 직접적으로 상속하지 않았음에도, 내부 구현이 이를 만족한다는 것만으로 타입 바인딩이 가능하다.

이러한 특성을 구조적 타이핑(Strutural Typing)이라고 한다.

다음은 자바의 경우이다.

// IHuman.java
interface IHuman {
  int MAX_AGE = 100;
  void setInfo(String name, String job);
  String introduce();
}

// Student.java
class Student {
  static final int MAX_AGE = 100;
  String name;
  String job;

  void setInfo(String name, String job) {
    this.name = name;
    this.job = job;
  }
  String introduce() {
    return "my name is " + this.name + " and my job is " + this.job;
  }
}


// Test.java
public class Test {
  public static void main(String[] args) {
    // IHuman 타입에 Student 인스턴스를 바인딩할 수 없다는 컴파일 에러 발생
    IHuman student = new Student();
    student.setInfo("luka","developer");
    System.out.println(student.introduce());
  }
}

위와 동일하게 자바의 경우에서도 IHuman 인터페이스를 직접 상속하지는 않지만,

내부 구현을 그대로 따르는 Student 클래스를 만들었다.

이 때 자바에서는 타입스크립트와는 달리 컴파일 에러가 발생한다.

자바에서는 컴파일 타임에서 타입 검사 시 인터페이스의 내부 구조를 따르는지 확인을 하는 것이 아닌, 인터페이스의 이름 자체를 가지고 검사를 수행하기 때문이다.

이러한 특성을 명목적 타이핑(Nominal Typing)이라고 한다.

 

런타임에서의 존재 여부

인터페이스에 대해 자바와 타입스크립트가 갖는 두번째 차이는 바로 런타임에서의 존재 여부이다.

타입스크립트에서 인터페이스를 작성하여 자바스크립트로 컴파일하면 어떻게 될까?

// human.interface.ts
interface Human {
  name: string;
  job: string;
  
  setInfo(name: string, job: string): void;
  introduce(): string;
}

위 코드를 컴파일할 경우 다음의 결과물이 나타난다.

// human.interface.js
"use_strict"

(아무 것도 없다!)

결과물에서 알 수 있듯이 타입스크립트에서 인터페이스는 컴파일 시 사라져 버린다.

즉 컴파일 타임까지만 유효한 개념이고, 런타임에서는 코드로서 존재하지 않는다.

타입스크립트를 통해 로직을 작성해보았다면, 누구나 타입 가드를 한번 쯤은 작성해보았을 것이다.

타입 가드란 런타임에서 특정 객체가 해당 객체의 타입이 가져야 할 메서드와 프로퍼티가 모두 잘 존재하는지 확인하고

그 결과에 따라 boolean을 반환하는 일종의 런타임 타입 검사를 수행하는 로직이라 생각하면 된다.

타입스크립트에서 타입 가드를 따로 작성해주어야 하는 까닭은, 결국 런타임에서 인터페이스와 같은 타입이 존재하지 않기 때문이다.

그렇다면 자바의 경우에는 어떨까.

자바의 경우, 인터페이스가 런타임에서 바이트 코드의 형태로 존재한다.

따라서 아래와 같은 로직도 가능하다.

// Student 클래스가 Human 인터페이스의 구현체라고 가정
const student = new Student();

// student가 Human의 실체화인지 확인
if(student instanceof Human) { 
  ...
} else {
  ...
}

만약 타입스크립트였다면,

if 문 내에서 student 인스턴스가 Human에서 정의한 특성들을 모두 구현하고 있는지 일일이 확인했어야 할 것이다.