TypeScript: Interfejsy

3.8+

0:00Interfejsy to kolejny temat, który będziemy

0:02poruszać w tym kursie. W prostych słowach są one pewnego rodzaju kontraktem

0:07opisującym to w jaki sposób ma wyglądać np.

0:10typ, funkcja lub klasa. I to co jest istotne

0:13to opisują one ich wygląd, ale nie mieszają się już do implementacji.

0:18Najlepiej jednak będzie gdy pokażę Ci to na przykładzie.

0:21Na ten moment wiemy już, że to jak wyglądają typy możemy opisywać poprzez

0:26tzw. aliasy typów. No to skoro tak to na czym polega różnica?

0:30A różnic jest tutaj przynajmniej kilka.

0:33Pierwszą z nich jest fakt, że interfejsy tworzą nową nazwę typu.

0:37Co to dokładnie oznacza zobaczmy

0:39na przykładzie. Mamy tutaj typ Player, który wykorzystujemy w naszej funkcji.

0:43Teraz analogicznie tworzę drugi typ Game,

0:46który również wykorzystam w parametrze funkcji.

0:49No i teraz po najechaniu na ten typ w tym miejscu,

0:52otrzymuję informację o całej jego strukturze.

0:56Natomiast w tym drugim przypadku otrzymuję skróconą informację o nazwie tego typu.

1:02Także jest to pierwsza różnica pomiędzy interfejsami oraz typami.

1:05Druga polega na tym, że w przypadku typów

1:08mamy możliwość tworzenia właściwości, które mają dynamiczny klucz czyli np.

1:13definiuję tutaj string literal type, które może przyjmować dwie wartości.

1:18I teraz mogę wykorzystać ten typ korzystając z następującego zapisu.

1:22Oznacza to dokładnie tyle, że typ Game

1:25posiada dwie właściwości: finite i infinite.

1:28W przypadku gdyby tych właściwości było

1:30więcej tego typu zapis mógłby okazać się pomocny. W przypadku interfejsów

1:35nie mamy takiej możliwości. Ale w zamian w przypadku interfejsów

1:39możemy mówić o tak zwanym łączeniu interfejsów, czyli jeżeli tutaj zdefiniuję

1:44jeden interfejs to definiując go ponownie poniżej otrzymam połączony interfejs.

1:50Czyli jeżeli do tej funkcji przekażę teraz obiekt zawierający jedną właściwość,

1:55od razu otrzymuję informację o tym, że muszę przekazać również drugą.

1:59I teraz wszystko jest w porządku.

2:01W przypadku gdybyśmy wykorzystali tutaj typy

2:04taka konfiguracja nie byłaby możliwa.

2:06Tymczasem kolejna przewaga interfejsów

2:09polega na tym, że mogą po sobie dziedziczyć.

2:12Zresztą odbywa się to na takiej samej zasadzie jak w przypadku klas.

2:16Po prostu definiując jakiś interfejs możemy określić jaki interfejs ma rozszerzać.

2:21Dzięki temu mamy naprawdę potężne

2:23narzędzie do tego, aby określać nowe interfejsy.

2:26Dodatkowo wewnątrz takiego interfejsu możemy określać właściwości opcjonalne,

2:31czyli takie które mogą, ale nie muszą znajdować się w interfejsie.

2:35Mało tego, gdyby zaistniała taka potrzeba,

2:38możemy również rozszerzać wiele interfejsów jednocześnie.

2:41Wystarczy, że ich nazwy podamy po przecinku.

2:44W takiej sytuacji interfejs Superadmin

2:47jest zobowiązany wypełnić kontrakty zarówno Admina, jak i Usera.

2:52No i w ten oto sposób prezentują się

2:54różnice pomiędzy interfejsami a aliasami typów.

2:57Dodatkowo, jak widzisz, różnica pomiędzy interfejsami a klasami abstrakcyjnymi polega

3:02na tym, że w klasach abstrakcyjnych możemy dodatkowo określić implementację

3:06poszczególnych metod a w przypadku interfejsów, tak jak powiedziałem

3:11na początku, możemy określać wyłącznie ich kształt.

3:14A teraz, jeżeli już jesteśmy przy temacie

3:16interfejsów, muszę powiedzieć Ci coś jeszcze na temat typów, co do tej pory

3:21pomijałem. Mianowicie TypeScript do weryfikacji typów wykorzystuje

3:25mechanizm, który nazywamy duck typing lub structural subtyping.

3:30W prostych słowach oznacza to, że typy

3:32weryfikowane są na podstawie tego jaki kształt posiada określona wartość.

3:36Często do wyjaśnienia tego mechanizmu używa się pewnej analogii.

3:40Zresztą to od niej pochodzi nazwa duck typing.

3:43Czyli jeżeli mamy coś co kwacze jak

3:46kaczka i chodzi jak kaczka to z dużą pewnością możemy stwierdzić, że faktycznie

3:50jest to kaczka. Ale oczywiście kaczką być nie musi.

3:54I wydaję mi się, że lepiej będzie jednak jak pokażę Ci to na przykładzie.

3:58Mianowicie mam tutaj interfejs Readable,

4:00który będzie określał dane, które da się przeczytać np.

4:04książki. I zwróć uwagę, że jedyną wymaganą właściwością jest tutaj właściwość pages.

4:10W momencie gdy zdefiniujemy drugi interfejs,

4:13którym będzie już sama książka, będzie ona posiadać również dodatkowe właściwości np.

4:18tytuł. No i teraz gdy utworzymy nowy obiekt na podstawie

4:21tego interfejsu możemy wykorzystać go funkcji. Ale zwróć uwagę, że

4:26ta funkcja tutaj oczekuje, że przekażemy do niej coś co da się przeczytać.

4:31A jeżeli teraz pomimo tego przekażemy do

4:34niej naszą książkę to nadal wszystko jest w porządku. I nawet sprawdzając to raz

4:39jeszcze mamy tutaj typ Book a tutaj spodziewamy się typu Readable.

4:44Pomimo tego dla TypeScriptu jest to jak najbardziej w porządku - w końcu książka

4:49jest czymś co da się przeczytać, ale z pewnością też stuprocentowym typem Readable

4:54jaki zdefiniowaliśmy tutaj nie jest. Bez wątpienia świadomość o tym w jaki sposób

5:00weryfikowane są typy jest czymś o czym powinieneś wiedzieć.

5:03W niektórych sytuacjach możesz wykorzystywać to na swoją korzyść

5:07a w niektórych sytuacjach możesz być po prostu świadomy, że coś może pójść nie tak.

5:11I na ten moment w kontekście interfejsów to wszystko.

5:15Więc zapraszam Cię do kolejnej lekcji.