TypeScript: Function overload

3.9+

0:00Kolejnym tematem które chciałbym poruszyć w tym kursie to tzw.

0:04Function overload czyli inaczej mówiąc przeciążenia funkcji.

0:08Chodzi o to że czasem jedną i tę samą

0:10funkcję chcemy zadeklarować na kilka różnych sposobów.

0:13Konkretnie mam tu na myśli sytuacje w których jedna funkcja przyjmuje różne

0:18argumenty lub nie wymaga od nas tego abyśmy podali od razu wszystkie argumenty.

0:23W samym Javascript nie mamy możliwości deklarowała wielu różnych funkcji

0:28natomiast w przypadku TypeScriptu sytuacja wygląda nieco inaczej.

0:32Warto jednak już na tym etapie zaznaczyć

0:35że przeciążenie funkcji nie polega na tworzeniu dwóch różnych funkcji tylko

0:39raczej na określaniu dwóch różnych typów tej samej funkcji.

0:43Najlepiej będzie jednak jak pokażę Ci to na przykładzie

0:47stawiam przed nami teraz następujący problem chcemy napisać funkcję która

0:52będzie wykonywała metodę uppercase ma ciągu znaków lub tablicy ciągu znaków.

0:58Teoretycznie taka funkcja mogłaby wyglądać tak że przy jej deklarowaniu

1:02przyjmowaliśmy dane dowolnego typu a następnie wykonywali na nich metodę.

1:07toUpperCase. Oczywiście takie coś nie do

1:10końca nam tutaj zadziała bo wystarczy że ze względu na to any przekażemy na

1:15przykład tablicę liczb. Chociaż z drugiej strony nawet jeżeli tutaj byłby tekst to

1:20dalej nasza funkcja nie zadziała ze względu na to że wykonała by metodę toUpperCase,

1:24bezpośrednio na tablicę a nie na jej elementach.

1:29Drugim rozwiązaniem które przychodzi do głowy jest zastosowanie wiedzy z

1:33poprzedniego filmu i zastąpienie typu any typem generycznym.

1:37Na ten moment wystarczy że skorzystamy tutaj z union type.

1:42W takiej sytuacji nasza funkcja zwróci string lub tablicę stringów.

1:47W tym momencie musimy również zmienić

1:49implementację naszej funkcji w taki sposób aby obsługiwała poszczególne typy.

1:53Więc jeżeli przekazane dane są typu string zwracamy to co mieliśmy wcześniej.

1:58W przeciwnym razie mamy tutaj do czynienia z tablicą.

2:01W związku z tym musimy wykonać metodę map w taki sposób aby wykonać metodę toUpperCase,

2:07na każdym z elementów tej tablicy.

2:09No i w tej chwili mamy już sytuację o którą dokładnie nam chodziło.

2:13Tutaj jeżeli zamienia argument tej funkcji na tablicę z stringów to otrzymam

2:18poprawny wynik i tak samo w sytuacji gdyby tutaj znalazły się np.

2:22moje imię.

2:24Również wszystko byłoby w porządku.

2:26Ostatecznie jednak w momencie gdy jedziemy na tę funkcję widzimy że mamy tutaj do

2:31czynienia ze stringiem lub tablicą stringów a następnie otrzymujemy string lub

2:36tablicę stringów. W tym konkretnym momencie.

2:39Moglibyśmy to jeszcze zaakceptować no ale w sytuacji gdybyśmy mieli do czynienia z

2:44większą liczbą typów bądź na przykład jakimiś klasami interfejsami itd.

2:48Nagle okazałoby się że tego typu

2:50informacja nie jest do końca dla nas czytelna.

2:53Chciałbym tutaj dojść do momentu w którym przekazując do funkcji string otrzymuję

2:58jasną informację o tym że z powrotem otrzymamy również string a nie np.

3:03tablicę stringów. Aby sobie z tym poradzić.

3:06Pierwszym takim najprostszym rozwiązaniem byłoby rozbicie tej funkcji na dwie.

3:10Jedna z nich obsługiwała by tekst a druga tablicę słów.

3:14Natomiast takie funkcje musiałyby się od

3:17siebie różnić nazwą bo jeżeli teraz zadeklaruje funkcję o tej samej nazwie to

3:21oczywiście mamy tutaj błąd wynikający z tego że nie możemy jednak tego zrobić.

3:27Powiedziałem jednak, że w TypeScript coś takiego jest możliwe i faktycznie jest to

3:32prawda ale na etapie określania typu a nie implementacji.

3:36Więc jeżeli teraz usuniemy ciało tej funkcji

3:38a następnie otworzymy kolejną deklarację obsługującą ten drugi przypadek no to

3:43nagle okazuje się, że żadnego błędu tutaj nie ma.

3:46I to nawet pomimo tego że te nazwy są dokładnie takie same.

3:50W sytuacji gdy przekazujemy do tej funkcji

3:53tablicę z treningów mamy tutaj jasną informację o tym że ta funkcja zwróci

3:58również tablice ciągów znaków. I jednocześnie w momencie gdy przekazujemy

4:02do tej tablicy z string taką samą informację otrzymujemy również z powrotem.

4:08I teraz tak samo w tej drugiej sytuacji w

4:10momencie gdy przekazujemy do funkcji string również mamy jasną informację o tym że

4:15otrzymamy w zamian string. I to czego tutaj doświadczyliśmy.

4:20To właśnie mechanizm przeciążenia funkcji.

4:22Czyli zadeklarowaliśmy jedną funkcję na wiele różnych sposobów a konkretnie

4:27określiliśmy różne typy tej samej deklaracji którą mamy tutaj.

4:32Dodatkowo dzięki odpowiedniej

4:33implementacji czyli wykorzystaniu tutaj union type oraz mechanizmu type guard o

4:38którym będziemy jeszcze mówić nagle okazało się, że TypeScript

4:42stał się zdecydowanie mądrzejszy w kontekście rozpoznawania tego jakie dane

4:47trafiają do funkcji oraz jakiego rodzaju dane mogą być z niej zwracane.

4:52I teraz jeżeli chodzi o function overload,

4:55jest kilka zasad których należy się definitywnie trzymać.

4:59Przede wszystkim nazwy wszystkich

5:00przeciążeń oraz samej funkcji muszą być dokładnie takie same.

5:05Następnie parametry oraz ich liczba przy

5:07każdym przeciążenia muszą się od siebie różnić.

5:10W tym konkretnym przypadku liczba akurat

5:13się nie różni ale różni się ich typ więc nie ma tutaj z tym problemu.

5:17W momencie jednak gdybyśmy z jakiegoś powodu popełnili błąd no to zadziała tylko

5:23to przeciążenie które zostało zadeklarowane jako pierwsze.

5:27Następnie kolejną ważną zasadą jest to że

5:30implementacja funkcji musi być zgodna z każdym zdefiniowanym przeciążeniem.

5:34Inaczej mówiąc musi obsługiwać każdy

5:37przypadek który zdefiniowaliśmy w przeciążenia.

5:40W momencie gdybyśmy nie mieli tutaj np. ifa

5:42albo zwracali jakieś inne dane skutkowałoby to wystąpieniem błędu

5:48i ostatnią zasadą jeżeli chodzi o przeciążenia jest to, że układamy je w

5:53kolejności od najbardziej konkretnego do najbardziej ogólnego. Czyli jeżeli

5:58zadeklarowali byśmy tutaj przeciążenie przyjmujące typ any

6:01no to za każdym razem to właśnie ono zostałoby wykorzystywane

6:06i zobacz że dzieje się nawet tak pomimo tego że tutaj mamy zadeklarowane

6:10przeciążenie bardziej precyzyjne ale już w momencie gdy zmienimy kolejność.

6:16Ten pierwszy przypadek zostanie obsłużonych według pierwszego przeciążenia

6:20a ten drugi według tego drugiego bardziej ogólnego.

6:24Ostatecznie pamiętaj też o tym że

6:26przeciążenia mogą dotyczyć różnej liczby argumentów.

6:29Zobaczmy to jednak na przykładzie. Mamy

6:32tutaj funkcję której działanie będzie się różniło w zależności od tego czy

6:36przekażemy do niej jeden argument czy też dwa.

6:39W momencie gdy ten drugi argument zostanie

6:41przekazany podzielimy pierwszy argument przez niego. W sytuacji jednak gdy ten

6:46argument nie będzie obecny podzielimy naszą liczbę przez dwa.

6:50No i teraz jesteśmy w sytuacji w której

6:53wykonanie tej funkcji nie zawsze zakończy się poprawnie.

6:56Ten błąd akurat wynika z tego że musimy

6:59ten parametr oznaczyć jako opcjonalny dodając tutaj znak zapytania.

7:03Ale nawet pomimo tego TypeScript nadal nie orientuję się dokładnie co się dzieje z

7:07przekazanymi danymi oraz jakie dane są zwracane kiedy.

7:11Dlatego też najlepiej będzie jeżeli

7:13zadeklaruje tutaj odpowiednie przeciążenia. Trzymając się teraz wszystkich zasad o

7:18których wspomniałem przed chwilą definiuje pierwsze przeciążenie które,

7:23obsługuje sytuację w której mamy do czynienia

7:25wyłącznie z jednym argumentem. Czyli jest to przeciążenie bardziej precyzyjne od

7:29tego w którym mamy do czynienia z dwoma argumentami. Ze względu na to że ten drugi

7:35parametr oznaczony jest jako opcjonalny, i nie mamy tutaj żadnej do myśli wartości.

7:39Wszystko jest w porządku. No i dodatkowo

7:42TypeScript odpowiednio odróżnia poszczególne przypadki.

7:46Mam nadzieję że to wszystko jest dla

7:48Ciebie jasne i na ten moment to wszystko słyszymy się za chwilę w kolejnej lekcji.