typescript docs 번역본 #2 (interfaces)

아래 링크는 원본입니다. 해석이 부족해도 양해 부탁드립니다..ㅎㅎ

www.typescriptlang.org/docs/handbook/interfaces.html

Handbook - Interfaces

 

````

Ts의 핵심 원리는 값이 가진 모양에 집중하는 type 확인 입니다. 이것은 종종 duck typing이나 structural subtyping이라 불립니다. Ts에서 인터페이스는 이것에 이름 짓는 역할을 수행하고, 외부 프로젝트의 코드 약속만큼 강력한 약속 정의 방식입니다.

 

 

우리의 첫번째 인터페이스

 

인터페이스가 작동하는 방식을 이해하는 가장 쉬운 방법은 간단한 예시로 시작하는 것입니다.

 

Type 확인은 printLabel 호출을 확인합니다. printLabel함수는 string 타입의 label이라 불리는 속성을 가진 객체를 파라미터로 가집니다. 우리의 객체는 이것보다 더 많은 속성을 가진 것을 신경 쓰고 있겠지만, 컴파일러는 오직 요구되는 한 개가 존재하는 지와 요구되는 타입인지만 확인합니다. Ts가 허술하지 않은 경우도 있습니다. 이는 우리가 나중에 다루겠습니다.

 

우리는 동일한 예제를 작성할 수 있습니다. 이번에는 string인 label 속성을 가진 요구사항을 나타내는 인터페이스를 사용해보겠습니다.

 

LabeledValue 인터페이스는 이전 예제의 요구사항을 나타내기 위해 사용할 수 있는 이름입니다. 그것은 여전히 string 타입의 label속성을 가집니다. 우리가 다른 언어에서 해야 하는 것처럼,  printLabel을 통과하는 객체가 인터페이스를 사용해야 한다고 명확하게 말할 필요는 없습니다. 오직 중요한 것은 모양입니다. 만약 함수를 통과하는 객체가 나열된 요구사항을 충족하면 됩니다.

 

Type 확인은 어떤 종류로 나열되었는지는 요구하지 않고, 오직 인터페이스가 요구하는 속성이 존재하는지와 요구된 타입을 가졌는지만 지적할 필요가 있습니다.

 

 

선택적 속성

인터페이스의 모든 속성은 요구되지 않을 것입니다. 특정 조건 속에서 존재하거나 그렇지 않을 수도 있습니다. 이 선택적 속성들은 당신이 오직 몇 가지 속성만 채워진 함수에 객체를 통과시기는 option bags와 같은 패턴을 만들 때, 이 선택적 속성들은 유용합니다.

 

여기 이 패턴의 예시가 있습니다.

 

선택적 속성을 사용한 인터페이스는 선언 속 각 속성의 이름 끝에 ?를 표기하는 식으로, 다른 인터페이스와 유사하게 작성됩니다

 

선택적 속성들의 이점은 인터페이스에 없는 속성을 예방하는 동안, 당신이 사용가능한 속성들을 나타내도록 해주는 것입니다. 예를 들어, 우리가 createSquare의 color 속성을 잘못 적으면, 우리는 에러를 받을 것입니다.

 

 

일기 전용 속성

몇몇 속성들은 객체가 처음 생성될 때에만 수정될 수 있어야 합니다. 당신은 속성의 이름 전에 readoly를 놓음으로써, 이것을 구현 할 수 있습니다.

 

당신은 객체 리터럴을 지정함으로써 Point를 구성할 수 있습니다. 지정 이후 x,y는 변경되지 못합니다.

 

Ts는 모든 돌연변이 함수가 제거된 array<T>와 같은 ReadonlyArray<T>와 함께 제공되므로, 생성후 배열을 변경하지 않도록 할 수 있습니다.

인용절의 마지막 줄에서, 당신은 할당된 ReadonlyArray  전체가 기존 배열로 돌아가지 못하는것을 볼 수 있습니다.

 

readonly vs const

readonly를 사용할지, const를 사용할지 기억할 가장 쉬운 방법은, 당신이 그것을 변수에 사용하는지 속성에 사용하는지 물어보는 것입니다. 속성들이 readonly를 사용하는 반면, 변수들은 const를 사용합니다.

 

 

지나친 속성 확인

인터페이스를 사용한 첫 번째 예시에서, Ts는 {label: string}만 예상된 것에, {size: number, label: string}를 통과하도록 했습니다. 또한 우리는 선택적 속성들과 option-bags를 나타낼 때 얼마나 유용한지 배웠습니다.

 

그러나, 단순히 두 개를 합치면, 에러가 발생합니다. createSquare을 이용한 마지막 예시를 다뤄보도록 하겠습니다.

 

createSquare에 주어진 독립변수가 color 대신 colour이라는 점을 주의하세요. 순수 Js에서 이 종류는 실패합니다.

 

당신은 물론 colour은 중요하지 않고, color은 없고, width은 맞아 떨어지기 때문에,  이 프로그램은 맞는 type이라 주장할 수 있습니다.

 

그러나 Ts는 이 코드에 문제가 있다는 자세를 취합니다. 객체 리터럴은 다른 변수에 할당하거나 그들을 독립변수로 통과시킬 때 특별한 처리를 하고,  excess property checking을 겪습니다. 만약 객체 리터럴이 타겟 type이 가지고 있지 않은 속성을 가지고 있으면, 에러가 발생할 것입니다.

 

이 checks을 확인하는 건 매우 쉽습니다. 가장 쉬운 방법은 type assertsion을 사용하는 것입니다.

 

그러나 만약 객체가 특별한 방법으로 사용되는 추가된 속성들을 가진다 확신한다면, 문자 인덱스 서명을 추가하는 게 가장 좋은 접근이다. 만약 SquareConfig가 위 타입으로 color와 width 속성을 가진다면, 그러나 또한 다른 속성값들을 가진다면, 우리는 이렇게 정의할 수 있습니다.

 

우리는 잠시 후에 인덱스 서명을 논의할 것이지만, 여기서 우리는 SquareConfig가 color와 width 도 아니고 type도 상관없는 임의의 속성을 가질 수 있다 말하고 있습니다.

 

약간은 놀라게 될 확인을 위한 최종 방식은, 객체를 다른 변수에 할당하는 것입니다. suqareOptions가 초과 속성 확인을 겪지 않기 때문에 컴파일러는 에러내지 않을 것입니다.

위의 해결방안은 squareOptions와 SquareConfig 사이에 공통 속성이 있는 한 작동합니다. 이 예제에서는 width 속성입니다. 만약, 변수가 공통된 객체 속성을 가지고 있지 않으면 실패합니다. 예를 들면:

 

위와 같은 간단한 코드의 경우, 이러한 검사를 피하려고 해서는 안됩니다. State를 가지거나 함수들을 가진 복잡한 객체 리터럴을 위해 당신은 이 기술들을 기억할 필요가 있지만, 초과 속성 에러들의 주는 실제 버그입니다. 그것은 만약 당신이 options-bag와 같은 무언가를 위해 초과 속성 확인 문제를 작동한다면, 당신의 type선언을 수정하길 원할 것임을 의미합니다. 이 경우에는 color와 colour속성을 가진 객체가 createSquare에  통과되는 게 괜찮다면, 당신은 반영을 위해 squareConfig의 정의를 수정해야 합니다.

 

 

함수 type들

인터페이스는 Js 객체들이 취할 수 있는 모든 모양을 표현할 수 있습니다. 속성이 있는 객체의 표현에 더해, 인터페이스는 함수 type도 묘사할 수 있습니다.

 

인터페이스에 있는 함수 타입이 있는 것을  설명하기 위해, 우리는 인터페이스에게 호출 서명을 줍니다. 이것은 마치 리턴 type이 주어지고 파라미터 리스트가 있는 함수 선언과 유사합니다. 파라미터 리스트의 각 파라미터는 name과 type 모두를 요구합니다.

 

한번 정의하면, 우리는 다른 인터페이스같이 함수 type 인터페이스를 사용할 수 있습니다. 여기에 어떻게 당신이 함수 타입 변수를 생성하는 지와 동일한 타입의 함수 변수를 지정하는 방식이 있습니다.

 

함수 type들이 맞는지 확인하기 위해, 파라미터들 이름은 맞을 필요가 없습니다. 예를 들어 우리는 위 예를 아래처럼 작성할 수 있습니다.

 

함수 파라미터들은 한번씩 확인되고, 파라미터 위치와 상응하는 type은 각각 확인 됩니다. 만약 당신이 type 전부를 구체화 하기 원하지 않으면, Ts의 상황에 맞는 타이핑은 함수 값이 SearchFunc type에 직접적으로 지정되었기 때문에, 요소 타입들을 추론할 수 있습니다. 또한 함수 표현 식의 리턴 타입은 SearchFunc이 리턴하는 값에 의해 암시됩니다(여기서는 true나 false입니다).

 

 

함수 표현식이 숫자나 문자를 리턴했다면, type 확인은 리턴 타입이 SearchFunc 인터페이스의 리턴 타입과 맞지 않음을 지적하는 에러를 만들 것입니다.

 

 

인덱싱 가능한 type

함수 type을 묘사하기 위한 인터페이스를 사용하는 방식과 유사하게, 우리는 a[10], ageMap[‘daniel’]과 같이 type들을 인덱스화 할 수 있습니다. 인덱싱 가능한 type들은 사용하는 type들을 객체의 인덱스로 표현하는 인덱스 서명을 가지고 있습니다. 예시를 보세요.

 

위에서, 인덱스 서명을 가지고 있는 StringArray 인터페이스가 있습니다. 이 인덱스 서명은 StringArray가 숫자로 인덱스 값이 정해질 때, 문자를 리턴하는 것을 정합니다.

 

여기 지원된 두 type(숫자, 문자)의 인덱스 서명이 있습니다. 모든 인덱스를 지원하는 것은 가능하지만, 숫자 인덱스로부터 리턴되는 type은 문자 인덱스로부터 리턴되는 type의 하위 type이 되어야합니다. 왜냐하면 숫자로 인덱싱 되면, Js는 그것을 객체로 인덱싱 되기 전에 문자로 전환할 것이기 때문입니다. 이는 숫자 100으로 인덱싱하는 것은 문자 “100”으로 인덱싱하는 것과 같음을 의미하므로, 두 항목이 일치해야 합니다.

 

문자 인덱스 서명이 사전 패턴을 묘사하기에 강력한 방식이지만,  그들은 모든 속성들이 그들의 리턴 타입과 같도록 강요합니다. 이는, 문자 인덱스가 obj[“property”]로도 사용가능한 obj.property을 선언하기 때문입니다. 아래 예시에서, name type은 string index의 타입과 맞지 않아 type 확인이 에러를 발생합니다.

 

그러나 인덱스 서명이 union type이라면 다른 타입의 속성들도 가능합니다.

 

 

마지막으로 인덱스를 지정하지 못하도록 막기 위해, read only 인덱스 서명을 사용할 수 있습니다.

 

인덱스 서명이 readonly이기에, 당신은 myArray[2]를 설정할 수 없습니다.

 

 

Class Types들

인터페이스 이행

 

C와 자바 같은 언어에서 공통적으로 가장 많이 사용하는, 클래스가 특정 약속을 충족하도록 하는 것은 Ts에서도 가능합니다.

 

당신은 클래스에 이행된 인터페이스 안에서 함수를 사용할 수 있습니다. 아래 예시 속 setTime처럼

 

인터페이스들은 public과 private모두보다, class의 public측면을 표현합니다. 이것은 class가 class 객체의 private 측면의 특정 타입들을 가지고 있는지 확인하기 위한 인터페이스 사용을 금지합니다.

 

클래스의 정적 측면과 인스턴스 측면의 차이점

 

클래스들과 인스턴스들로 함께 작업할 때, 클래가 static 측면과 instance 측면의 타입을 가지고 있음을 의식하는 것은 유용합니다. 만약 당신이 construct 서명이 있는 interface를 생성하고 이 인터페이스를 이행하는 class를 생성하려 하면, 이 인터페이스는 에러를 발생합니다.

 

이것은 클래스가 인터페이스를 이행할 때, 오직 인스턴스 측면만 확인되기 때문입니다. Constructor은 정적인 측면에 있기에, 그것은 이 확인에 포함되지 않습니다.

 

대신에, 당신은 클래스의 정적인 측면을 직접적으로 쓰고 싶을 겁니다. 이 예시에서 우리는 두 인터페이스, constructor의 ClockConstructor과 인스턴스 함수의 ClockInterface들을 정의합니다. 그러고 편리함을 위해, 그것이 통과되는 type의 인스턴스들을 생성하는 createClock constructor 함수를 정의합니다.

 

createClock(AnalogClock, 7, 32)에서 createClock의 첫 번째 파라미터의 타입은  ClockConstructor이기 때문에, AnalogClock이 맞는 constructor 서명을 가지고 있는지 확인합니다.

 

다른 간단한 방식은 클래스 표현식을 사용하는 것입니다.

 

 

확장된 인터페이스들

클래스들과 마찬가지로, 인터페이스들도 각각 확장시킬 수  있습니다. 이것은 당신이 한 개의 인터페이스를 다른 하나에 복사하도록 해주고, 당신이 인터페이스들을 재사용 가능한 컴포넌트로 분리하는 유연성을 제공합니다.

 

 

인터페이스는 모든 인터페이스들의 조합을 만들면서, 여러 인터페이스들로 확장할 수 있습니다

 

 

하이브리드 type들

인터페이스들은 Js에 존재하는 다양한 타입들을 표현할 수 있다고 앞서 언급했었습니다. Js는 동적이고 유연하기 때문에, 당신은 위에서 묘사된 타입들의 조합으로 동작하는 객체를 만났을 것입니다.

 

객체와 함수 모두를 추가 속성들로 동작하는 객체가 있는 예시가 있습니다.    

    

 

Js의 3rd-party와 상호작용할 때, 당신은 위와 같이 type모양을 표현하기 위해, 패턴들을 사용하고 싶을 겁니다.

 

 

클래스들을 확장하는 인터페이스들

인터페이스 type이 클래스 type을 확장할 때, 그들의 이행물이 아닌 클래스를 상속합니다. 그것은 마치, 인터페이스는 구현을 제공하지 않고, 클래스의 모든 멤버들을 선언하는 것과 같습니다. 인터페이스는 기초 클래스의 protected, private 요인들을 상속합니다. 이것은 private, protected 요인을 가진 클래스를 확장하는 인터페이스를 생성할 때, 그 인터페이스 type은 그 클래스나 하위 클래스에 의해서만 이행됩니다.

 

이것은 거대한 상속성을 가지고 있지만, 특정 속성을 가진 하위 클래스들과만 당신의 코드가 작동하기를 원할 때 유용합니다. 하위 클래스는 기초 클래스로부터 상속받은 것과 관계가 있을 필요는 없습니다. 예를 들면

 

 

 

위 예에서 SelectableControl은 private state속성을 포함한 Control을 가지고 있습니다. State가 private이기에, Control의 자손만 SelectableControl을 실행할 수 있습니다. 이는, Control의 자손만이 동일한 선언에서 비롯되는 private state를 가지기 때문이며, private 멤버가 호환되기 위한 요구 사항입니다.

 

 

Control 클래스내에서, SelectableControl 인스턴스를 통해 private state에 접근하는 것은 가능합니다. 효과적으로, SelectableControl은 select method를 가진 것으로 알려진 Control처럼 작동합니다. Button과 TextBox 클래스들은  SelectableControl의 하위 type입니다(왜냐하면 그들 모두 Control로부터 상속받았고, select method를 가졌기 때문입니다). ImageControl 클래스는 확장된 Control이 아닌, 고유의 private state를 가지고 있기에 SelectableControl을 이행하지 못합니다.

 

````