Wszystko jest obiektami

1.1 Obiekty i klasy

Dzisiaj dowiesz się, jak zbudowany jest typowy program w JavaScript. I najważniejsza wiadomość: każdy program w JavaScript składa się z klas i obiektów. JavaScript to język zorientowany obiektowo, a wszystko w nim to obiekty: liczby, łańcuchy znaków, funkcje, a nawet klasy.

Co to są klasy?

Zaczniemy od analogii. Wyobraź sobie, że chcesz zbudować mały statek. Najpierw musisz stworzyć plan, a potem zanieść go do fabryki, gdzie na jego podstawie zostanie zbudowany statek. Albo kilka. A w zasadzie, ile tylko chcesz. Na podstawie jednego planu można zbudować dziesiątki identycznych statków, co jest ważne.

W programowaniu w JavaScript jest dokładnie tak samo.

Plany

Programista to taki projektant. Tylko że projektant rysuje plany, a programista JavaScript pisze klasy. Następnie na podstawie planów tworzone są części, a na podstawie klas — obiekty.

Najpierw piszemy klasy (robimy plany), a potem, podczas działania programu, na ich podstawie JavaScript tworzy obiekty. Dokładnie tak, jak statki są tworzone na podstawie planów.

Plan jest jeden, ale statków może być wiele. Statki są różne, mają różne nazwy, przewożą różne towary. Ale są bardzo podobne: wszystkie są statkami o identycznej konstrukcji i mogą wykonywać podobne zadania.

Albo inna analogia...

Mrowisko

Mrowisko to dobry przykład współpracy obiektów. W prosty mrowisku są trzy klasy mrówek: królowa, wojownicy i robotnice.

Liczba mrówek każdej klasy jest różna. Królowa jest jedna na całe mrowisko, wojowników są dziesiątki, a robotnic setki. Trzy klasy i setki obiektów. Mrówki współpracują ze sobą, z innymi mrówkami tego samego i innych klas, zgodnie ze ściśle określonymi zasadami.

To idealny przykład. W typowym programie wygląda to tak samo. Jest główny obiekt, który tworzy obiekty wszystkich pozostałych klas. Obiekty zaczynają współpracować ze sobą i z „zewnętrznym światem” programu. Wewnątrz tych obiektów ich zachowanie jest ściśle określone.

Te dwa wyjaśnienia to dwie strony tej samej monety. Prawda leży pośrodku. Pierwszy przykład (o planie i statkach) pokazuje związek między klasą i obiektami tej klasy. Jest to bardzo mocna analogia. Drugi przykład (o mrowisku) pokazuje związek między obiektami istniejącymi podczas działania programu a napisanymi klasami.

Najpierw musisz napisać klasy dla wszystkich obiektów istniejących w programie, a potem opisać ich współpracę. Brzmi to trochę skomplikowanie, ale jest łatwiejsze, niż się wydaje.

W JavaScript wszystkie jednostki podczas działania programu to obiekty, a pisanie programu sprowadza się do opisu różnych sposobów współpracy obiektów. Obiekty po prostu wywołują metody nawzajem i przekazują im odpowiednie dane.

Dokumentacja

Jak dowiedzieć się, jakie dane przekazać do metod? Wszystko już zostało wymyślone za ciebie.

Zazwyczaj każda klasa ma opis, w którym jest napisane, do czego została stworzona. Wszystkie publiczne metody mają także opis: co robią i jakie dane trzeba im przekazać.

Aby korzystać z klasy, musisz ogólnie wiedzieć, co ona robi. Musisz także dokładnie wiedzieć, co robi każda jej metoda. Nie musisz jednak wiedzieć, w jaki sposób to robi. To taka magiczna różdżka.

Spójrzmy na kod — kopiowanie pliku:

    
      const fs = require('fs');

      // Otwórz pliki
      const src = fs.createReadStream('source.txt');
      const dst = fs.createWriteStream('destination.txt');

      // Skopiuj zawartość z source.txt do destination.txt
      src.pipe(dst);

      // Zamknij pliki po zakończeniu kopiowania
      src.on('end', () => {
        src.close();
        dst.close();
      });
    
  

Jeśli przeczytasz ten kod linijka po linijce, możesz zgadnąć, co ogólnie on robi. Choć tu potrzebne jest doświadczenie i praktyka. Po pewnym czasie ten kod wyda ci się znajomy i zrozumiały.

1.2. Projektowanie programu

Projektowanie programu to prawdziwa sztuka. Jest zarówno łatwe, jak i trudne jednocześnie. Łatwe, bo nie ma sztywnych zasad: wszystko, co nie jest zakazane, jest dozwolone. Ale trudne z tego samego powodu: jest wiele sposobów, żeby coś zrobić i trudno wybrać najlepszy.

Projektowanie programu to jak pisanie książki. Z jednej strony po prostu piszesz litery, słowa, zdania. A z drugiej — ważna jest fabuła, charaktery bohaterów, wewnętrzne konflikty, styl narracji, intryga itd.

Najważniejsze jest zrozumienie, dla kogo piszesz kod. A kod piszesz dla innych programistów.

Tworzenie dowolnego produktu to wprowadzanie zmian: coś dodane tutaj, coś usunięte tam, coś zmienione gdzie indziej. I w ten sposób, małymi iteracjami, powstają duże, ogromne i gigantyczne projekty.

Najważniejsze wymaganie dotyczące kodu to powinien być zrozumiały dla innych programistów. Niepoprawny, ale zrozumiały kod można poprawić. Poprawnego i niezrozumiałego kodu nie da się ulepszyć. Pozostaje tylko go wyrzucić.

Jak więc pisać dobry i zrozumiały kod?

W tym celu musisz robić trzy rzeczy:

• Pisz dobry i zrozumiały kod wewnątrz metod — to najprostsze
• Decyduj, jakie jednostki powinny być w programie
• Poprawnie dziel program na logiczne części

Co kryje się za tymi pojęciami?

Pisz dobry kod wewnątrz metod

Jeśli znasz chociaż podstawowy angielski, być może zauważyłeś, jak łatwo czasami czytać kod — jak zdania w języku angielskim:

• class Cat extends Pet — klasa Cat rozszerza klasę Pet
• while (stream) — dopóki strumień nie jest pusty ...
• a < b ? a : b — jeśli a jest mniejsze niż b, zwróć a, w przeciwnym razie zwróć b

Jest to zrobione celowo. JavaScript to jeden z języków, w którym łatwo pisać samodokumentujący się kod: kod, który jest zrozumiały bez komentarzy. W dobrym kodzie w JavaScript wiele metod czyta się jak zdania w języku angielskim.

Twoim zadaniem podczas pisania kodu jest również sprawienie, by był jak najprostszy i najkrótszy. Po prostu pomyśl, jak łatwo będzie czytać twój kod i zacznij iść w dobrym kierunku.

W JavaScript powszechnie przyjęte jest pisanie łatwo czytelnego kodu. Pożądane jest, aby cała metoda mieściła się na ekranie (długość metody — 20-30 linii). To norma w całej społeczności JavaScript. Jeśli kod można ulepszyć, należy go ulepszyć.

Najlepszy sposób na naukę pisania dobrego kodu to ciągła praktyka. Pisz dużo kodu, studiuj kod innych, poproś bardziej doświadczonych kolegów o przeprowadzenie przeglądu twojego kodu. I pamiętaj, że w momencie, kiedy powiesz sobie „to wystarczy”, twój rozwój się zatrzyma.

Decyduj, jakie jednostki powinny być w programie

Musisz pisać kod, który jest zrozumiały dla innych programistów. Jeśli 9 na 10 programistów podczas projektowania programu zrobi w nim klasy A, B i C, to ty również powinieneś zrobić w swoim programie klasy A, B i C. Musisz pisać kod, który jest zrozumiały dla innych.

Świetny, działający, szybki, niestandardowy kod to zły kod.

Musisz studiować projekty innych ludzi: to najlepszy, najszybszy i najłatwiejszy sposób na przyswojenie całej mądrości, która gromadziła się przez dziesięciolecia w branży IT.

I, nawiasem mówiąc, masz już w ręku świetny, popularny, dobrze udokumentowany projekt — React. Zacznij od niego.

Analizuj klasy i struktury klas. Zastanów się, dlaczego niektóre metody są statyczne, a inne nie. Dlaczego metody mają takie, a nie inne parametry. Dlaczego właśnie takie metody, dlaczego klasy nazywają się w ten sposób i znajdują się w takich pakietach.

Kiedy zaczynasz rozumieć odpowiedzi na te pytania, będziesz w stanie pisać kod, który jest zrozumiały dla innych.

Jednak chcę cię ostrzec przed analizowaniem kodu w metodach D3.js. Kod wielu metod został przepisany w celu maksymalizacji szybkości działania — jego czytelność jest wątpliwa.

Poprawnie dziel program na logiczne części

Każdy program zazwyczaj dzielimy na części lub moduły. Każda część odpowiada za swój aspekt programu.

Komputer ma jednostkę centralną, monitor, klawiatury, i są to wszystko oddzielne, mało zależne części. Co więcej, ich współdziałanie jest znormalizowane: USB, HDMI itp. Jeśli więc wylejesz kawę na klawiaturę, możesz po prostu umyć ją pod kranem, wysuszyć i korzystać dalej.

A laptop to przykład architektury monolitycznej: logiczne części niby są, ale są znacznie silniej zintegrowane. W Macbook Pro, aby wyczyścić klawiaturę, trzeba rozebrać połowę laptopa. A wylana na nią kawa — to powód, by zamówić nowy. Tylko nie kawę.

1.3 Tworzenie własnych klas

Dopiero uczysz się programować, więc musisz zacząć od małych kroków — nauki tworzenia własnych klas.

Oczywiście, już je tworzyłeś, ale musisz nauczyć się rozumieć, jakie klasy powinny być w programie, jak powinny się nazywać, jakie powinny mieć metody. I jak powinny ze sobą współdziałać.

Lista jednostek

Jeśli nie wiesz, od czego zacząć, zacznij od początku.

Na samym początku projektowania programu możesz po prostu wypisać na kartce listę jednostek (obiektów), które powinny być w programie. A potem zaprogramować je zgodnie z zasadą: każda jednostka — osobna klasa.

Przykład

Załóżmy, że chcesz napisać grę w szachy. Będziesz potrzebował takich jednostek: szachownica i 6 typów figur. Figury poruszają się różnie, mają różne wartości — logiczne, że to osobne klasy. I w ogóle, na samym początku, im więcej klas — tym lepiej.

Znaleźć początkującego programistę, który zamiast dwóch klas napisałby dziesięć — to rzadkość. Zamiast dziesięciu napisać dwie, a czasem jedną — to nowicjusze uwielbiają. Tak że więcej klas, drodzy programiści. I wasz kod stanie się bardziej zrozumiały dla wszystkich, może z wyjątkiem was 😛

Szachy

Załóżmy, że zdecydowaliśmy się napisać klasy do szachów: jak te klasy by wyglądały?

Szachownica to po prostu tablica 8 na 8? Lepiej stwórz dla niej oddzielną klasę, która wewnątrz przechowuje odniesienie do tablicy. Wówczas w klasie „szachownica” będziesz mógł dodać wiele przydatnych metod, które na przykład sprawdzają, czy pole jest puste czy zajęte.

W ogóle, na początku zawsze można kierować się zasadą: Program ma różne Jednostki, a Jednostka ma typ. Ten typ to właśnie klasa.