WEBVTT

1
00:00:00.000 --> 00:00:00.923
こんにちは。

2
00:00:00.923 --> 00:00:05.541
タイプスクリプト入門、第四回はインターフェースとタイプです。

3
00:00:05.541 --> 00:00:07.542
前回は基本型を学びました。

4
00:00:07.542 --> 00:00:13.698
今回は、複数の項目を持つオブジェクトの形を、名前を付けて定義する方法を学びます。

5
00:00:13.698 --> 00:00:16.469
中心になるのがインターフェースです。

6
00:00:16.469 --> 00:00:23.549
インターフェースは、オブジェクトが持つプロパティやメソッドの型を決める契約のようなものです。

7
00:00:23.549 --> 00:00:30.321
必須の項目、省略できる項目、書き換えを防ぐ項目を区別し、クラスが満たすべき形も表せます。

8
00:00:30.321 --> 00:00:35.246
後半では、同じく型に名前を付けるタイプとの使い分けも整理します。

9
00:00:35.246 --> 00:00:42.172
この回を終えるころには、オブジェクトにどんな型を付ければよいかが判断できるようになります。

10
00:00:42.172 --> 00:00:45.718
まず、インターフェースでユーザーの形を定義します。

11
00:00:45.718 --> 00:00:48.696
アイディーとネームは必須のプロパティです。

12
00:00:48.696 --> 00:00:54.653
ニックネームの後ろにあるクエスチョンマークは、省略できる任意のプロパティを表します。

13
00:00:54.653 --> 00:00:59.191
省略できる項目を読むとき、その型はストリングかアンディファインドのどちらかになるため、

14
00:00:59.191 --> 00:01:03.729
値がない場合の扱いを考える必要があります。

15
00:01:03.729 --> 00:01:10.679
ここでは、クエスチョンを二つ重ねた演算子で、ニックネームがないときはネームを使うようにしています。

16
00:01:10.679 --> 00:01:15.926
アイディーに付けたリードオンリーは、型チェックの上で再代入を防ぐ指定です。

17
00:01:15.926 --> 00:01:21.032
ただし、実行時にオブジェクトを凍結する処理ではない点に注意してください。

18
00:01:21.032 --> 00:01:27.692
タイプスクリプトの特徴は、名前ではなく形で互換性を判断する点です。

19
00:01:27.692 --> 00:01:30.719
これを構造的型付けと呼びます。

20
00:01:30.719 --> 00:01:37.984
たとえば、ネームという文字列だけを求めるインターフェースがあるとします。

21
00:01:37.984 --> 00:01:48.882
引数に渡すオブジェクトが、その型を明示的に宣言していなくても、必要なネームを持っていれば渡すことができます。

22
00:01:48.882 --> 00:01:56.550
記事数が入った別の項目を持っていても、変数を経由する場合は問題になりません。

23
00:01:56.550 --> 00:02:01.495
インターフェースは、余分な項目が一切ないことを常に保証する仕組みではない、

24
00:02:01.495 --> 00:02:06.439
と理解しておきましょう。

25
00:02:06.439 --> 00:02:11.081
必要な形が合うかどうか、それが判断の基準です。

26
00:02:11.081 --> 00:02:20.364
これはクラスで作った値にも当てはまり、作り手と使い手が緩やかに結び付く理由にもなっています。

27
00:02:20.364 --> 00:02:26.656
ただし、オブジェクトリテラルを直接、代入や引数として渡す場面では、話が少し変わります。

28
00:02:26.656 --> 00:02:33.388
このときは余剰プロパティ検査と呼ばれるチェックが働き、型にない項目を書くとエラーになります。

29
00:02:33.388 --> 00:02:39.388
先ほどの例をリテラルのまま直接渡すと、ティーエス二三五三というエラーで止まります。

30
00:02:39.388 --> 00:02:43.119
一見すると不便ですが、プロパティ名の書き間違いを早い段階で見つけられる、

31
00:02:43.119 --> 00:02:46.851
ありがたい仕組みでもあります。

32
00:02:46.851 --> 00:02:50.217
変数経由では通るのに、直接書くとエラーになる。

33
00:02:50.217 --> 00:02:55.192
この違いを知っておくと、エラーメッセージの理由を追いやすくなります。

34
00:02:55.192 --> 00:02:59.156
インターフェースは、クラスの契約としても使えます。

35
00:02:59.156 --> 00:03:06.610
スピーカーというインターフェースに、ネームと、文字列を返すスピークというメソッドを定義します。

36
00:03:06.610 --> 00:03:15.490
クラスでインプリメンツ・スピーカーと書くと、そのクラスが必要な形を満たしているかをコンパイラが検査してくれます。

37
00:03:15.490 --> 00:03:18.662
メソッドが足りなければエラーになります。

38
00:03:18.662 --> 00:03:25.322
ただし、インプリメンツは実装を自動で作る機能でも、処理を継承する機能でもありません。

39
00:03:25.322 --> 00:03:26.749
あくまで検査です。

40
00:03:26.749 --> 00:03:33.410
型だけを読み込むインポート・タイプは、ジャバスクリプトの出力には残らず消去されます。

41
00:03:33.410 --> 00:03:41.180
クラスで作ったインスタンスも、通常のオブジェクトも、同じスピーカーとして共通に扱えるのが利点です。

42
00:03:41.180 --> 00:03:46.001
インターフェースには、拡張と宣言マージという特徴があります。

43
00:03:46.001 --> 00:03:49.938
拡張は、エクステンズというキーワードで既存のインターフェースを引き継ぎ、

44
00:03:49.938 --> 00:03:53.875
項目を追加する仕組みです。

45
00:03:53.875 --> 00:04:00.946
アニマルという基本の形に、犬種を表す項目を加えてドッグを作る、といった使い方ができます。

46
00:04:00.946 --> 00:04:09.142
もう一つの宣言マージは、同じ名前のインターフェースを複数回宣言すると、項目が自動的に合体する性質です。

47
00:04:09.142 --> 00:04:13.320
ライブラリーの型を後から拡張したい場面で役立ちます。

48
00:04:13.320 --> 00:04:20.712
この二つは、後で学ぶタイプにはない、インターフェースならではの性質として覚えておきましょう。

49
00:04:20.712 --> 00:04:26.268
一方のタイプは、型に別名を付ける仕組みで、オブジェクトの形も同じように書けます。

50
00:04:26.268 --> 00:04:30.019
タイプが得意なのは、オブジェクト以外の型への命名です。

51
00:04:30.019 --> 00:04:34.394
たとえば、下書きか公開済みかという候補を並べたユニオン型や、数値二つの組み合わせを表すタプルにも、

52
00:04:34.394 --> 00:04:38.770
名前を付けることができます。

53
00:04:38.770 --> 00:04:45.299
単純なオブジェクトの定義であれば、インターフェースでもタイプでも、どちらを使っても構いません。

54
00:04:45.299 --> 00:04:50.299
拡張やマージを使いたいならインターフェース、ユニオンなどをまとめたいならタイプ、

55
00:04:50.299 --> 00:04:55.300
というように、表現したい内容とプロジェクトの方針で選びましょう。

56
00:04:55.300 --> 00:04:59.660
ファイルに分けた例は、実際にコンパイルして確かめましょう。

57
00:04:59.660 --> 00:05:07.178
メインのファイルを指定してコンパイルすると、読み込んでいるスピーカーのファイルも一緒に処理されます。

58
00:05:07.178 --> 00:05:15.146
ストリクトを有効にし、ターゲットやモジュールの指定を付け、エラーがあれば出力を止めるオプションも加えます。

59
00:05:15.146 --> 00:05:19.506
実行すると、猫のインスタンスからはミケ、にゃー、オブジェクトで作った案内係からは、

60
00:05:19.506 --> 00:05:23.866
案内係、ようこそ、と表示されます。

61
00:05:23.866 --> 00:05:30.632
型チェックが通ることと、実行結果が期待どおりであること、その両方を確認する習慣が大切です。

62
00:05:30.632 --> 00:05:31.959
大切な注意点です。

63
00:05:31.959 --> 00:05:35.498
インターフェースは、実行時の検証ではありません。

64
00:05:35.498 --> 00:05:42.429
エーピーアイから受け取った値にユーザーという型を付けただけでは、中身の形は一切確認されません。

65
00:05:42.429 --> 00:05:49.654
インターフェースはジャバスクリプトの出力に残らないため、インスタンスオブで調べることもできません。

66
00:05:49.654 --> 00:05:57.764
外部からの入力は、まずアンノウンとして受け取り、必要なプロパティがあるかを自前の処理で確かめる必要があります。

67
00:05:57.764 --> 00:06:04.105
インターフェースの役割は、検証を終えた後のコードで、値を安全に扱いやすくすることです。

68
00:06:04.105 --> 00:06:06.612
この境界を意識して設計しましょう。

69
00:06:06.612 --> 00:06:09.643
最後に、設計のコツを二つ紹介します。

70
00:06:09.643 --> 00:06:13.515
一つ目は、関数が求める型は小さく表すことです。

71
00:06:13.515 --> 00:06:19.324
大きなデータ全体を要求するのではなく、その関数が実際に読む項目だけをインターフェースにすると、

72
00:06:19.324 --> 00:06:25.133
さまざまなオブジェクトを渡しやすくなります。

73
00:06:25.133 --> 00:06:28.837
二つ目は、任意項目を増やしすぎないことです。

74
00:06:28.837 --> 00:06:34.393
すべてを省略可能にすると、使う側で何度も存在確認が必要になります。

75
00:06:34.393 --> 00:06:39.865
状態によって必須の項目が変わる場合は、種類を示す項目で判別できるユニオン型に分けると、

76
00:06:39.865 --> 00:06:45.337
不正な組み合わせそのものを表せなくなります。

77
00:06:45.337 --> 00:06:52.240
小さな契約を積み重ねる考え方は、この後の関数やクラスの学習でもそのまま役立ちます。

78
00:06:52.240 --> 00:06:53.129
まとめです。

79
00:06:53.129 --> 00:06:58.015
インターフェースは、オブジェクトの必須項目、任意項目、リードオンリーを表す契約であり、

80
00:06:58.015 --> 00:07:02.902
クラスへのインプリメンツでも形を検査できます。

81
00:07:02.902 --> 00:07:11.788
タイプスクリプトは名前ではなく形で判断する構造的型付けを採用し、リテラルを直接渡す場合だけ余剰プロパティ検査が働きます。

82
00:07:11.788 --> 00:07:20.673
使い分けでは、拡張や宣言マージが要る場合はインターフェース、ユニオンやタプルに名前を付けたい場合はタイプが向いています。

83
00:07:20.673 --> 00:07:25.856
そして、インターフェースは実行時の検証ではない点も忘れないでください。

84
00:07:25.856 --> 00:07:31.039
次回は第五回として、関数の引数、戻り値、オーバーロードの型を学びます。

85
00:07:31.039 --> 00:07:32.372
お疲れさまでした。