W zeszłym tygodniu wygłosiłem prezentację na WordCamp Atlanta na temat przestrzeni nazw i automatycznego ładowania. (pełny tytuł to Przestrzenie nazw, automatyczne ładowanie i ulepszanie architektury wtyczek, ale to kęs, prawda?)
Ze względu na charakter rozmowy zdecydowałem się napisać post towarzyszący postowi, udostępnić slajdy i udostępnić przykładową wtyczkę GitHub, aby wesprzeć rozmowę.
Więc jeśli byłeś obecny, dziękuję (!) i oto post, obiecałem. A dla tych z Was, którzy nie uczestniczyli, mam nadzieję, że ten post nadal pomoże zademonstrować koncepcje i tematy , które omawiałem na WordCamp.
Przestrzenie nazw i automatyczne ładowanie
Zanim omówię przestrzenie nazw i automatyczne ładowanie w WordPressie, chcę o tym porozmawiać, ponieważ może to bezpośrednio wpłynąć na jakość kodu i może to robić przez wiele miesięcy i lat.
W końcu niewielu z nas, programistów, zadaje już pytanie:
Jak możemy uczynić nasz kod lepszym niż jest?
A wielu z nas jest wystarczająco inteligentnych, by wiedzieć to, czego nie wiemy. Mamy więc do czynienia z pracą w ramach ograniczeń, które są nam dane.
Czasami mamy czas, aby zbadać, jak to zrobić; innym razem pracujemy z wiedzą, którą posiadamy. I nie ma w tym nic złego.
Ale ponieważ wiemy to, czego nie wiemy, wiemy, że istnieje potencjał na więcej.
Po pierwsze, Twój kod
Jeśli chodzi o poruszanie tematów takich jak przestrzenie nazw i automatyczne ładowanie w kontekście WordPressa, myślę, że często spotykamy się z mieszanymi odpowiedziami.
W końcu moglibyśmy rozmawiać o takich rzeczach jak The Theme Customizer lub REST API lub o czymś bardziej zabawnym.
Chodzi mi o to, że „przestrzenie nazw i automatyczne ładowanie" po prostu nie brzmi ekscytująco ani postępowo w porównaniu z nowszymi dostępnymi funkcjami i technologiami, prawda?
Ale nie, tak naprawdę nie są nudne. W tym poście i towarzyszącej mu prezentacji oraz kodzie źródłowym pokażę, dlaczego i dlaczego tak nie jest.
Nie są nudni
Myślę, że można uczciwie powiedzieć, że programiści – przynajmniej część z nas lub ich część, w zależności od tego, jak siebie postrzegasz – są znani z kłótni o aspekty programowania.
– I tak nudna rozmowa.
W rzeczywistości nie jest niczym niezwykłym słyszeć, jak ktoś kłóci się o najlepszy sposób na zainicjowanie i napisanie pętli for, która jest tak wydajna, jak to możliwe podczas iteracji na małym zestawie bazy danych, pomimo faktu, że mamy czterordzeniowe procesory i 16 GB pamięci RAM w naszych komputerach stacjonarnych.
Jeśli więc tak bardzo zależy nam na czymś tak małym, na pewno zależy nam na szerszym obrazie. Rzeczy takie jak:
- Ulepszony kod
- Lepsza organizacja
- Zwiększona łatwość konserwacji
- Łatwiejsze debugowanie
- Zarabianie więcej pieniędzy (no, może).
A przestrzenie nazw i automatyczne ładowanie mogą prowadzić bezpośrednio do wszystkich powyższych (cóż, nie mogę mówić o pieniądzach, ale ma potencjał).
Gdybym miał podsumować przestrzenie nazw ról i miejsce automatycznego ładowania we wszystkich powyższych, powiedziałbym, że:
Przestrzenie nazw i automatyczne ładowanie prowadzą do ulepszonego kodu poprzez lepszą organizację, podział na sekcje lub modularyzację oraz ściślejszą relację poprzez ich koncepcje.
Co więcej, zwiększa to łatwość konserwacji, ponieważ kod jest zorganizowany w pakiety, co może prowadzić do łatwiejszego debugowania w miarę rozwoju produktu.
Wszystko to może prowadzić do oszczędności czasu lub lepszego wykorzystania czasu, co w zależności od modelu biznesowego może mieć wpływ na wyniki finansowe.
Ale to nadal nie opisuje żadnej z tych rzeczy. Ale z pewnością w tym momencie brzmią bardziej interesująco niż wtedy, gdy zostały wprowadzone po raz pierwszy.
Więc czym one są?
Zanim przejdziemy do definicji każdego z nich i ról, jakie pełnią, przyjrzyjmy się, jak brak przestrzeni nazw i automatyczne ładowanie w WordPressie negatywnie wpłynęło na twoje doświadczenie podczas korzystania z motywów, wtyczek, dodatków lub czegokolwiek innego.
Cofnijmy się więc na chwilę i przyjrzyjmy się każdemu z osobna.
Przestrzenie nazw
Wyobraź sobie, że odziedziczyłeś projekt i zaraz zaczniesz nad nim pracować. Powiedz, że to wtyczka WordPress.
Instalujesz go; idziesz go aktywować, a następnie dostajesz co najmniej jedno z tych:
- Być może widzisz tę paskudną wiadomość porządkową u góry okna przeglądarki wyświetlającą ślad stosu.
- Może widzisz komunikat mówiący o jakimś konflikcie z innym istniejącym pakietem.
- A może, gdy próbujesz aktywować wtyczkę, strona odświeża się, ale wtyczka się nie aktywuje.
- Być może wykonałeś nawet audyt kodu i widzisz sprawdzanie class_exists w całej bazie kodu.
Dowolne lub wszystkie z powyższych mogą oczywiście przyczynić się do problemów z projektami WordPress. Ale przestrzenie nazw mogą naprawdę naprawić wiele z tych problemów w większości przypadków.
Oznacza to, że przyczyną tych problemów jest to, że kod, z którym pracujesz, jest w całości częścią globalnej przestrzeni nazw (w przeciwieństwie do jej przestrzeni nazw) a PHP nie lubi kiedy istnieją klasy i moduły o tej samej nazwie .
Ale kiedy tworzysz coś w przestrzeni nazw, dajesz mu jej obszar względem siebie, który nadal będzie ładnie współpracował z innymi komponentami, nawet jeśli mają tę samą nazwę klasy.
Autoloadery
Jeśli chodzi o automaty ładujące, są one pod pewnymi względami mniej skomplikowane. Najpierw pomyśl o kodzie, który piszesz lub o kodzie, z którym pracujesz – zwłaszcza w kontekście wtyczek WordPress – a następnie zastanów się, ile razy piszesz lub widzisz następujące rzeczy:
Czasami widzisz je na górze pliku, który uruchamia wtyczkę, a czasami widzisz je porozrzucane po całym kodzie.
Jeśli wszystkie są zawarte w jednym pliku, nie jest tak źle, ponieważ przynajmniej wiesz, gdzie się znajdują. Ale jeśli są zaśmiecone wszędzie, to nie masz pojęcia, gdzie do systemu wprowadza się zależność.
Automatyczne ładowanie może rozwiązać ten problem, ładując zależności w razie potrzeby (a dla tych, którzy są zainteresowani, automatyczne ładowanie jest szybsze niż ręczne włączenie).
Przestrzenie nazw
Mając to wszystko na uwadze, jesteśmy gotowi porozmawiać o przestrzeniach nazw i automatycznym ładowaniu. Ale przestrzenie nazw to podstawowa koncepcja, więc od tego zaczniemy.
Ale po tym wszystkim możesz zobaczyć zalety ich używania. Może nawet są zabawne, prawda? Może?
Niezależnie od tego potrzebujemy definicji, nad którą możemy pracować, omawiając to do końca artykułu.
Podręcznik PHP zawiera następującą definicję :
Przestrzenie nazw mają na celu rozwiązanie dwóch problemów, które napotykają autorzy bibliotek i aplikacji podczas tworzenia elementów kodu wielokrotnego użytku, takich jak klasy lub funkcje…
I to nie jest złe, ale jest dość długie, techniczne i może być trochę za dużo dla tych, którzy dopiero zaczynają. Więc uprośćmy to trochę w tym artykule:
Może trochę lepiej?
Sposób grupowania powiązanych klas i interfejsów o podobnym przeznaczeniu.
W tym wystąpieniu nie będę mówił o interfejsach; wiem jednak, że używają ich średniozaawansowani programiści zorientowani obiektowo, więc chciałem się upewnić, że przynajmniej o nich wspomniałem.
Praktyczny przykład
Nie lubię przykładów programowania, które nie dają rzeczywistych lub praktycznych zastosowań. Często otrzymujemy przykłady rzeczy, których nigdy byśmy nie skodyfikowali.
Ile razy czytałeś artykuł zorientowany obiektowo i podaje on przykład klasy zwierząt lub klasy samochodu? Nie będziemy programować samochodu.
Bardziej prawdopodobne jest, że będziemy pracować z plikami. Przyjrzymy się więc zestawowi klas odpowiedzialnych za odczytywanie i zapisywanie plików. To znaczy, byliśmy dobrymi programistami zorientowanymi obiektowo i rozdzieliliśmy nasze klasy w oparciu o obowiązki, które utrzymują.
I tak, możesz mieć interfejsy; jednak wykraczają one poza zakres tego artykułu, więc nie zostaną uwzględnione.
Więc dla naszego FileReadera, być może podstawy tej klasy wyglądają tak:
Klasa do czytania plików.
Zauważ, że funkcja akceptuje nazwę pliku, który powinna otworzyć do odczytu. Sprawdzanie błędów, sposób, w jaki odczytuje plik i co zwraca, jest pozostawione implementacji klasy.
A dla FileWriter mamy coś takiego:
Klasa do zapisywania plików.
Z drugiej strony ta klasa akceptuje informacje, które zamierza zapisać na dysku i nazwę pliku, do którego powinna zostać zapisana.
Ponownie, tak jak w powyższym przykładzie, nie obejmuje sprawdzania błędów, zapisywania poprzez zasób, zamykania zasobów i tak dalej.
Ale tu nie chodzi o pracę z plikami. Zamiast tego chodzi o pokazanie, jak utworzyć przestrzeń nazw w kodzie, a te dwa przykłady mają być do tego fundamentalne.
Uwagi dotyczące przestrzeni nazw
Istnieje zastrzeżenie dotyczące tego, co widzisz na obrazach przykładowego kodu powyżej: te klasy nie mają przestrzeni nazw. To znaczy, że znajdują się w globalnej przestrzeni nazw, co sprawia, że są gotowe do konfliktów z innymi klasami.
Spójrz na to w ten sposób: wyobraź sobie, że pakujesz ten kod do wtyczki dla kogoś innego, a następnie ładujesz inną wtyczkę, która również ma funkcję FileReader lub FileWriter. Ponieważ to wszystko będzie częścią tej samej globalnej przestrzeni nazw, będziesz musiał zmierzyć się z konfliktem.
Pamiętać:
Przestrzenie nazw to sposób na grupowanie powiązanych klas i interfejsów o podobnym przeznaczeniu.
Weźmy więc klasy i przestrzeń nazw kod.
Najpierw udostępnimy przestrzeń nazw najwyższego poziomu, w której będą znajdować się te klasy i wszystkie inne; wtedy dostarczymy podpakiet (lub podprzestrzeń nazw lub podprzestrzeń, jak słyszałem, jak je nazywano), w którym będą rezydować te klasy plików.
Oznacza to, że nasz FileReader będzie teraz wyglądał tak:
Klasa przestrzeni nazw do odczytywania plików.
A nasz FileWriter będzie teraz wyglądał tak:
Klasa przestrzeni nazw do zapisywania plików.
Po pierwsze, możesz zobaczyć, że używanie przestrzeni nazw jest łatwe: po prostu używasz słowa kluczowego namespace, a następnie deklarujesz przestrzeń nazw (która może równie dobrze być WCATL) na górze z następującymi podpakietami.
Ale to prowadzi do innych tematów – a mianowicie dotyczących organizacji plików, tworzenia instancji i automatycznego ładowania – z których wszystkie są warte omówienia.
W organizacji plików
W tym momencie ważne jest, aby mieć słowo na temat organizacji plików. W zależności od tego, z kim rozmawiasz, przekonasz się, że niektórzy programiści – niespodzianka, niespodzianka – mają opinię na temat tego, jak powinny być zorganizowane pliki (i ja nie jestem inny).
Z jednej strony nie musisz w ogóle organizować swoich plików. W rzeczywistości możesz wrzucić każdą rzecz do katalogu głównego projektu, umieścić informacje w przestrzeni nazw i być gotowym do pracy.
Niezorganizowane pliki
Powyższy zestaw plików dotyczy małego projektu, więc możesz sobie wyobrazić, ile plików istniałoby dla dużego projektu.
Ale kiedy masz swoje pliki zorganizowane w ten sposób, może to utrudnić pisanie autoloadera, ponieważ autoloader musi wiedzieć, gdzie znaleźć pliki na podstawie ich przestrzeni nazw.
Tutaj w grę wchodzą terminy „organizacja logiczna” i „organizacja wirtualna”.
- Organizacja logiczna odnosi się do tego, jak pliki są zorganizowane na dysku, tak jak to widać powyżej. Są one logicznie zlokalizowane w katalogu głównym.
- Organizacja wirtualna odnosi się do sposobu organizacji plików w odniesieniu do ich przestrzeni nazw. Oznacza to, że istnieją katalogi i podkatalogi, które są mapowane na przestrzenie nazw, podpakiety i tak dalej.
Więc gdybyś wziął powyższy projekt, jego przestrzenie nazw, jego podpakiety, a następnie uporządkował je logicznie i wirtualnie, wyglądałby to mniej więcej tak:
Przestrzenie nazw i automatyczne ładowanie: zorganizowane pliki
I chociaż możesz zdecydować się na organizowanie plików w dowolny sposób, jestem fanem upewniania się, że istnieje równość między nimi. Oznacza to, że podoba mi się moja logiczna i wirtualna organizacja, jak widać na powyższym obrazku.
Gdy przejdę do omawiania automatycznego ładowania, zobaczysz, dlaczego ma to znaczenie.
Uwagi dotyczące przestrzeni nazw
Co się jednak dzieje, gdy musimy tworzyć instancje klas, które są w przestrzeni nazw? Gdy klasy nie mają przestrzeni nazw, łatwo jest użyć słowa kluczowego „new”.
Instancja bez przestrzeni nazw.
Ale musimy utworzyć instancję klasy z przestrzenią nazw, musimy pójść o krok dalej i użyć w pełni kwalifikowanej nazwy:
Przestrzenie nazw i automatyczne ładowanie: tworzenie wystąpień z przestrzenią nazw.
Ale to staje się kłopotliwe, prawda? Ten konkretny przykład nie jest taki zły, ale wyobraź sobie, że pracujesz nad czymś z większą liczbą podpakietów. Byłoby to dość kłopotliwe, prawda?
W tym celu możemy użyć tzw. aliasingu. To też jest proste. Możemy zdefiniować użycie słowa kluczowego ‘use’ na górze pliku, aby odwołać się do przestrzeni nazw, którą chcemy aliasować, a następnie użyć ostatniego podpakietu jako części aliasu, aby utworzyć instancję naszej klasy.
Brzmi myląc, prawda? Być może zobaczenie tego w akcji pomoże:
Aliasy przestrzeni nazw.
I to wszystko. Tak, możesz pójść o krok dalej w aliasie, ale na tym polegam w kontekście tego artykułu.
Automatyczne ładowanie
W tym momencie mamy już przygotowane podstawy do automatycznego ładowania. Tak, praca z przestrzeniami nazw może być bardzo pracochłonna, jeśli nie jesteś do tego przyzwyczajony; jednak ważne jest, aby zrozumieć, ponieważ automatyczne ładowanie wymaga trochę pracy, która może być nieoczekiwana, jeśli nigdy wcześniej nie byłeś z tym zapoznany.
Niezależnie od tego, najważniejsze rzeczy do zapamiętania dotyczące przestrzeni nazw w tym momencie to:
- Przestrzenie nazw to sposób na grupowanie powiązanych klas i interfejsów o podobnym przeznaczeniu.
- Utwórz parzystość w plikach i przestrzeniach nazw, upewniając się, że Twoja logiczna i wirtualna organizacja są takie same.
A teraz nadszedł czas, aby przyjrzeć się automatycznemu ładowaniu.
Uwagi dotyczące automatycznego ładowania
Najpierw spójrzmy na definicję automatycznego ładowania podaną w podręczniku PHP :
Funkcja spl_autoload_register() rejestruje dowolną liczbę autoloaderów, umożliwiając automatyczne ładowanie klas i interfejsów, jeśli nie są one aktualnie zdefiniowane. Rejestrując autoloadery, PHP otrzymuje ostatnią szansę na załadowanie klasy lub interfejsu, zanim zawiedzie z powodu błędu.
Nie jest źle. Jednak to jest długie. Tak jak w przypadku przestrzeni nazw, użyjmy krótszej definicji w tym artykule:
Sposób na automatyczne ładowanie interfejsów i klas bez użycia instrukcji include i require.
Ponownie, nie będziemy używać interfejsów w tym artykule, chociaż niektórzy programiści to robią. I to będzie stanowić roboczą definicję pozostałej części tego artykułu.
Praktyczny przykład
Po uporządkowaniu plików, przestrzeni nazw i gotowości do załadowania nadszedł czas, aby to zrobić, prawda? To znaczy:
- twoje pliki są uporządkowane,
- jesteś gotowy, aby je załadować
Więc czas zrobić to automatycznie, prawda? Ale jest pewien haczyk. Całe „automatyczne ładowanie” plików wymaga trochę pracy.
Pisanie Autoloadera
Oznacza to, że jest to automatyczne, ale nadal wymaga trochę więcej pracy z naszej strony. Zanim przejdziesz do tych kroków, ważne jest, aby pamiętać:
- nie jest w pełni zautomatyzowany,
- musimy to napisać.
Choć byłoby to miłe, gdyby kod był automatycznie ładowany, musimy odczytać pewne dane, przeanalizować je, a następnie spróbować załadować odpowiedni plik.
Ale zakładając, że napiszesz to poprawnie, swoją przestrzeń nazw i zorganizujesz swoje pliki w ten sam sposób dla każdego projektu, możesz ponownie użyć swojego autoloadera. Oznacza to, że piszesz go raz i możesz go używać w innych projektach.
Kroki dla autoloadera
Podczas pisania autoloadera należy wykonać tylko kilka kroków. Autoloader musi być w stanie odpowiedzieć na następujące pliki:
- Gdzie są pliki?
- Jak się nazywają?
- Czy plik istnieje?
Jeśli wszystkie powyższe są prawdziwe (lub możesz odpowiedzieć „tak” na wszystkie), to autoloader zrobi to, co powinien.
Za chwilę przyjrzymy się kodowi, ale pierwszą rzeczą, na którą należy zwrócić uwagę, jest to, że używa on funkcji o nazwie spl_autoload_register.
SPL odnosi się do Standardowej Biblioteki PHP, a funkcja akceptuje funkcję jako argument, a ta funkcja przyjmuje nazwę klasy, która ma zostać utworzona. Jest bardziej proceduralny niż obiektowy i powiem o tym za chwilę, ale ważne jest, aby pamiętać podczas czytania tego kodu.
Oto pierwsza część kodu. Wyjaśnię, co robi po fakcie:
Automatyczne ładowanie, część 1 – Znajdowanie klasy
W tej części kodu funkcja otrzymuje w pełni kwalifikowaną nazwę klasy, która ma zostać utworzona (np. „WCATLFileFileReader()”).
Następnie rozdziela wszystkie części w pełni kwalifikowanej nazwy na części. Nazwa klasy jest ostatnim indeksem tablicy, a ja decyduję się nazwać moje pliki „class-filereader.php”, aby funkcja tworzyła zmienną $class_file, która odnosi się do nazwy pliku.
Ale jeszcze nie skończyliśmy. Nadal musimy uzyskać w pełni kwalifikowaną nazwę (czyli miejsce, w którym plik znajduje się na dysku). To może wyglądać mniej więcej tak:
Automatyczne ładowanie, część 2 – Uzyskanie w pełni kwalifikowanej nazwy
W tym momencie przygotowujemy zmienną $full_qualified_path, która będzie odnosić się do katalogu najwyższego poziomu.
Następnie kod przechodzi przez wszystkie indeksy tablicy i tworzy ścieżkę do pliku klasy. Możesz sobie to wyobrazić jako budowanie ciągu, takiego jak „wcatlfile”, który następnie łączymy z $class_file.
Oznacza to, że w pełni kwalifikowana ścieżka do pliku staje się „wcatlfileclass-filereader.php”.
I na koniec dołączamy plik. Zauważ, że ten kod nie sprawdza, czy plik istnieje. Chociaż polecam, został pominięty ze względu na długość i ponieważ w naszym przykładzie wiemy, że plik istnieje.
Jeśli plik nie istnieje, istnieje kilka opcji:
- Zrzuć wyjątek,
- Złap wyjątek,
- Wyświetl własny komunikat o błędzie,
- Lub jakaś inna opcja, którą rozważam w tym artykule.
Niezależnie od tego, chodzi o to, aby w kodzie działać defensywnie, aby móc przygotować się na przypadek, że plik nie istnieje i z wdziękiem poradzić sobie z awarią.
Po automatycznym ładowaniu
Przed zakończeniem warto zwrócić uwagę na następujące kwestie:
- W całym przykładzie używaliśmy kodu zorientowanego obiektowo podczas tworzenia przestrzeni nazw kodu. W końcu jest to koncepcja zorientowana obiektowo.
- Nasz autoloader jest napisany w kodzie proceduralnym. Co daje?
Ostatecznie ma to związek ze standardową biblioteką PHP. Możesz napisać autoloader zorientowany obiektowo, ale myślę, że w wielu przypadkach jest to trochę przesada.
Proces ładowania pliku jest procesem krok po kroku, więc pisanie go w sposób proceduralny jest naturalnym rozwiązaniem.
Wreszcie, inni mogą zdecydować się na użycie narzędzi takich jak Composer, aby wprowadzić zależności. To świetne narzędzia, a używanie czegoś takiego ma wiele zalet; jednak wykracza to poza koncepcje i tematy zawarte w tym artykule i najlepiej pozostawić je na przyszłą rozmowę.
Zasoby (i dziękuję!)
To był jeden z najdłuższych artykułów, jakie napisałem dla mojej witryny.
Dzieje się tak częściowo dlatego, że opiera się na rozmowie dla WordCamp, a także dlatego, że chcę się upewnić, że zapewnię solidne wprowadzenie i podstawę, od której możesz zacząć włączać przestrzenie nazw i automatyczne ładowanie do wtyczek WordPress.
Oprócz tego artykułu udostępniłem również następujące zasoby:
- Slajdy mojej prezentacji są dostępne na SpeakerDeck.
- Mam kod z tej prezentacji do pobrania na GitHub.
I z tym mam nadzieję, że jest to solidne wprowadzenie do przestrzeni nazw i automatycznego ładowania i że będziesz w stanie zacząć włączać to coraz bardziej do swojej pracy. To bardzo przyniesie korzyści Twojej pracy i innym programistom, którzy mogą również skorzystać z Twojej pracy.