Wszystko jest obiektami

1.1 Obiekty i klasy

Dzisiaj dowiesz się, jak zorganizowany jest typowy program w Pythonie. I najważniejsza wiadomość: każdy program w Pythonie składa się z klas i obiektów. Python to język zorientowany obiektowo i wszystko w nim jest obiektami: liczby, łańcuchy tekstowe, funkcje, a nawet klasy są obiektami.

Więc czym są klasy?

Zacznę od analogii. Wyobraź sobie, że chcesz zrobić mały statek. Najpierw musisz zrobić projekt, potem oddać go do fabryki, gdzie według tego projektu zostanie zbudowany statek. Albo i dziesięć. Tak naprawdę, tyle ile chcesz. Według jednego projektu buduje się dziesiątki identycznych statków, to jest ważne.

W programowaniu w Pythonie jest dokładnie tak samo.

Projekty

Programista jest jak projektant. Tylko że projektant rysuje projekty, a programista Python pisze klasy. Następnie na podstawie projektów tworzone są części, a na podstawie klas – obiekty.

Najpierw piszemy klasy (robimy projekty), a potem, podczas wykonywania programu, na podstawie tych klas Python tworzy obiekty. Dokładnie tak, jak statki są tworzone na podstawie projektów.

Projekt jeden, ale statków może być wiele. Statki są różne, mają różne nazwy, przewożą różne ładunki. Ale są bardzo podobne: wszystkie są statkami z identyczną konstrukcją i mogą wykonywać podobne zadania.

Albo jeszcze inna analogia...

Mrowisko

Mrowisko to dobry przykład interakcji między obiektami. W najprostszym mrowisku są trzy klasy mrówek: królowa, wojownicy i pracownicy.

Liczba mrówek każdej klasy jest różna. Królowa jest jedna na całe mrowisko, wojowników jest dziesiątki, a pracowników setki. Trzy klasy i setki obiektów. Mrówki współpracują ze sobą, z innymi mrówkami i mrówkami innych klas według ściśle określonych zasad.

To jest idealny przykład. W typowym programie jest identycznie. Jest główny obiekt, który tworzy obiekty wszystkich innych klas. Obiekty zaczynają współpracować ze sobą i z „zewnętrznym światem” programu. Wewnątrz tych obiektów jest sztywno zaprogramowane ich zachowanie.

Te dwa wyjaśnienia to dwie strony jednej monety. Prawda jest pośrodku. Pierwszy przykład (o projekcie i statkach) pokazuje związek między klasą a obiektami tej klasy. Analogicznie jest bardzo silnie. Drugi przykład (o mrowisku) pokazuje związek między obiektami, które istnieją podczas działania programu, a napisanymi klasami.

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

W Pythonie wszystkie jednostki podczas działania programu są obiektami, a pisanie programu sprowadza się do opisu różnych sposobów interakcji obiektów. Obiekty po prostu wywołują metody innych i przekazują do nich potrzebne dane.

Dokumentacja

A jak dowiedzieć się, jakie dane przekazywać do metod? Tu już wszystko wymyślono przed tobą.

Zwykle każda klasa ma opis, który mówi, do czego została stworzona. Zwykle każdy publiczny metoda ma również opis: co robi i jakie dane należy do niej przekazać.

Aby użyć klasy, musisz ogólnie wiedzieć, co robi. A także musisz dokładnie wiedzieć, co robi każda jej metoda. I wcale nie musisz wiedzieć, jak to robi. Taka magiczna różdżka.

Spójrzmy na kod – kopiowanie pliku:

src = open('source.txt', 'r')
dst = open('destination.txt', 'w')
            
for line in src:
    dst.write(line)
            
src.close()
dst.close()
        

Jeśli przeczytasz ten kod linię po linii, możesz się domyśleć, co on ogólnie robi. Choć tu potrzebne jest doświadczenie i praktyka. Tak więc po pewnym czasie ten kod będzie ci się wydawał znajomy i zrozumiały.

1.2. Projektowanie programu

Projektowanie programu to całe sztuka. To jednocześnie proste i skomplikowane. Proste, bo nie ma żadnych sztywnych reguł: wszystko, co nie jest zabronione, jest dozwolone. No a skomplikowane też z tego powodu: jest wiele sposobów, jak coś zrobić i niełatwo znaleźć 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, charakterystyki postaci, wewnętrzne sprzeczności, konflikty, styl narracji, intryga itp.

Najważniejsze to zrozumieć, dla kogo piszesz kod. Pamiętaj, że twój kod jest przeznaczony dla innych programistów.

Tworzenie dowolnego produktu to dokonywanie zmian: dodajesz tu, usuwasz tam, przerabiasz gdzieś indziej. I tak, małymi iteracjami, powstają wielkie, ogromne i gigantyczne projekty.

Główne wymaganie co do kodu – musi 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 go tylko wyrzucić.

Więc jak pisać dobry i zrozumiały kod?

Trzeba robić trzy rzeczy:

• Pisać dobry i zrozumiały kod wewnątrz metod – to najprostsze.
• Zdecydować, jakie jednostki powinny być w programie.
• Poprawnie podzielić program na logiczne części.

Co kryje się za tymi pojęciami?

Pisać dobry kod wewnątrz metod

Jeśli znasz choćby podstawowy poziom angielskiego, być może zauważyłeś, jak czasem łatwo czyta się kod: jak zdania w języku angielskim:

• class Cat(Pet) – klasa Cat rozszerza klasę Pet.
• while stream: – dopóki strumień nie jest pusty ...
• a if a < b else b – jeśli a jest mniejsze od b, zwróć a, w przeciwnym razie zwróć b.

Tak zrobiono specjalnie. Python to jeden z kilku języków, w którym łatwo pisać samodokumentujący się kod: kod, który jest zrozumiały bez komentarzy. W dobrym kodzie w Pythonie wiele metod czyta się jak zdania po angielsku.

Twoim zadaniem przy pisaniu kodu jest również uczynić go jak najprostszym i najbardziej zwięzłym. Po prostu myśl o tym, jak łatwo twój kod będzie czytać i zaczniesz zmierzać w dobrym kierunku.

W Pythonie jest przyjęte pisać łatwy do czytania kod. Zaleca się, aby każda metoda mieściła się w całości na ekranie (długość metody – 20-30 linii). To norma dla całej społeczności Python. 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, analizuj cudzy kod, proś bardziej doświadczonych kolegów o przegląd twojego kodu. I pamiętaj, że w momencie, gdy powiesz sobie „jest dobrze”, twoje rozwijanie się zatrzyma.

Zdecydować, jakie jednostki powinny być w programie

Musisz pisać kod zrozumiały dla innych programistów. Jeśli 9 z 10 programistów przy projektowaniu programu stworzy w nim klasy A, B i C, to ty również powinieneś zrobić w swoim programie klasy A, B i C. Musisz pisać kod zrozumiały dla innych.

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

Musisz analizować inne projekty: to najlepszy, najszybszy i najłatwiejszy sposób przejęcia całej mądrości, która przez dekady gromadziła się w branży IT.

A, swoją drogą, masz już pod ręką doskonały, popularny, dobrze udokumentowany projekt – Python SDK. Zacznij od niego.

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

Kiedy zaczniesz rozumieć odpowiedzi na te pytania, będziesz mógł pisać kod zrozumiały dla innych.

Jednak chcę cię ostrzec przed analizowaniem kodu w metodach Python SDK. Kod wielu metod został przepisany w celu maksymalizacji szybkości działania – jego czytelność jest pod dużym znakiem zapytania.

Poprawne dzielenie programu na logiczne części

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

Komputer ma jednostkę centralną, monitor, klawiaturę, i to wszystko są osobne, mało zależne części. Co więcej, ich interakcja jest wystandaryzowana: USB, HDMI itp. Ale jeśli wylejesz kawę na klawiaturę, możesz ją po prostu umyć pod kranem, wysuszyć i dalej używać.

A laptop to przykład monolitycznej architektury: logiczne części niby są, ale są o wiele ściślej zintegrowane. W Macbooku Pro, żeby wyczyścić klawiaturę, musisz rozebrać połowę laptopa. A wylać kawę na laptop to powód, żeby zamówić nowy. Tylko nie kawę.

1.3 Tworzenie własnych klas

Kiedy dopiero zaczynasz programować, ważne jest, aby zacząć od małych rzeczy – nauczyć się tworzyć własne klasy.

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 według zasady: każda jednostka to osobna klasa.

Przykład

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

Spotkanie początkującego programisty, który zamiast dwóch klas napisałby dziesięć, to duża rzadkość. Ale zamiast dziesięciu napisać dwie lub nawet jedną – to nowicjusze lubią. Więc więcej klas, drodzy programiści. I wasz kod stanie się bardziej zrozumiały dla wszystkich, oprócz może was 😛

Szachy

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

Szachownica to po prostu tablica 8 na 8? Lepiej zrób dla niej osobną klasę, która wewnątrz przechowuje odnośnik do tablicy. Wtedy do klasy „szachownica” będziesz mógł dodać wiele przydatnych metod, które na przykład sprawdzają, czy pole jest puste czy zajęte.

Ogólnie, 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.