Jedną z najłatwiejszych rzeczy, które możemy zrobić podczas pracy z wtyczkami WordPress, jest pominięcie instrukcji require_once lub include_once w całym kodzie.
Czemu nie? Jest to łatwy sposób na wprowadzenie wszystkich niezbędnych plików lub zależności dla danej klasy, czytelność i nie musisz martwić się tworzeniem ogromnych plików kodu. Oznacza to, że pomaga nam uprościć to, co piszemy, tak abyśmy mogli sprawić, by nasze klasy [głównie lub idealnie] robiły to, co robią dobrze.
Jeśli jednak czytałeś tę stronę przez ostatni rok, wiesz, że jestem fanem automatycznego ładowania i myślę, że każdy pracujący z PHP – niezależnie od tego, czy używasz WordPressa, czy innej platformy – powinien posługiwać się.
Ale rodzi to dwa pytania, zwłaszcza jeśli dopiero zaczynasz:
- Po co zawracać sobie głowę automatycznym ładowaniem, skoro istnieją inne sposoby obsługi zależności ładowania?
- W jaki sposób automatyczne ładowanie wypada w porównaniu z językami skompilowanymi?
Pomyślałem więc, że warto odpowiedzieć na to pytanie w kilku następnych postach.
Po co zawracać sobie głowę automatycznym ładowaniem?
W skrócie to:
- require_once i include_once mogą prowadzić do kodu trudnego do debugowania,
- trudno jest namierzyć kod.
Ale jak to możliwe?
1 Debugowanie jest trudne
Podczas pisania kodu, jeśli coś jest pewne, to jest to, że będzie coś, co nie działa zgodnie z przeznaczeniem. To leży w naturze tego, co robimy, prawda?
Więc kiedy przychodzi czas na debugowanie kodu, wszyscy mamy swoje strategie.
- niektórzy z nas decydują się na użycie echo lub var_dump do śledzenia kodu,
- korzystać z wtyczki w WordPressie,
- inni używają debugera.
Chociaż ten post nie dotyczy debugowania, to fakt, że musimy debugować. Więc jeśli wiemy, że będziemy musieli to zrobić, czy nie powinniśmy zrobić tego tak łatwo dla siebie, jak to tylko możliwe?
PHP jest językiem dynamicznie typowanym, więc generalnie jest wiele rzeczy, którymi zajmujemy się za każdym razem, gdy piszemy kod. Oznacza to, że pewne rzeczy są wywnioskowane lub wymuszane za każdym razem, gdy kod jest uruchamiany.
Załóżmy na przykład, że pracujesz z ciągiem i porównujesz go z liczbą. Interpreter zrobi wszystko, co w jego mocy, aby odgadnąć, co robisz (czy chcesz przetworzyć ciąg na liczbę całkowitą czy odwrotnie?), a następnie z tym pracować.
Praca z samymi zmiennymi może być ćwiczeniem z precyzją, ponieważ chcemy, aby nasz kod był czytany zgodnie z naszymi intencjami. Po co zgadywać tłumaczowi, o co nam chodzi? A jeśli tłumacz musi wykonać dodatkową pracę, z pewnością robią to ludzie.
W tym celu, jeśli wiemy, że zostaną wprowadzone błędy i wiemy, że istnieją sposoby na napisanie czystszego kodu, dlaczego mielibyśmy tego nie zrobić?
2 Śledzenie jest trudne (a może trudniejsze?)
Ale to nadal nie dostarcza powodu, dla którego powinniśmy polegać na czymś takim jak autoloader w porównaniu z wbudowanymi funkcjami języka, prawda?
Rozważ to: powiedzmy, że przeglądasz plik, próbując znaleźć błąd i natrafiasz na funkcję, która ma jakiś kod, używa include_once, a następnie używa innego kodu.
Oznacza to, że musisz przeczytać kod, zachować go w myślach, przeskoczyć do innego pliku, zrozumieć ten kod, a następnie wrócić do oryginalnego pliku. Zakłada się, że drugi plik również nie zawiera ani nie wymaga innych plików.
Nie bez powodu nazywa się to kodem spaghetti.
Mając to na uwadze, możesz zobaczyć kłopoty, jakie to wprowadza, gdy zdecydujesz się zagnieździć ten kod w pozostałej części programu. Krótko mówiąc, zagnieździłeś włączanie zależności, co z natury utrudnia śledzenie, gdzie coś może pójść nie tak.
Nie oznacza to, że automatyczne ładowanie automatycznie to naprawia, ale oznacza to, że nie musi tak być. Zamiast tego możesz napisać kod, który tworzy wystąpienia klas, wywołuje metody, a następnie wykonuje kod bez konieczności ręcznego dołączania czegokolwiek.
Bardziej czytelny, identyfikowalny kod
Robiąc to, stwierdzam, że zmusza nas to do pisania czystszego kodu, prawdopodobnie bardziej łatwego w utrzymaniu kodu. Ułatwia to również pisanie kodu, który możemy łatwiej śledzić i który jest łatwiejszy do wykorzystania za pomocą debugera.
Oznacza to, że możemy ustawić punkty przerwania w niektórych miejscach w naszym kodzie, sprawić, że debuger automatycznie przeniesie nas do wywoływanej klasy i wyjdzie z powrotem do funkcji, która ją wywołała.
Nie oznacza to, że nie można tego zrobić w inny sposób, ale korzyści znacznie przewyższają alternatywy. I oczywiście nadal pozostaje pytanie, dlaczego automatyczne ładowanie (lub jakiekolwiek włączanie plików stron trzecich) jest w ogóle potrzebne.
Ale to właśnie zostanie omówione w drugiej części serii.
Inne czytanie
Mój post na temat Przestrzenie nazw i automatyczne ładowanie w WordPressie, a także Simple Autoloader dla WordPressa, to dwa inne zasoby, które oczywiście znalazłem w związku z tym konkretnym postem. Więc jeśli masz czas, sprawdź je (i nie wahaj się otworzyć problemu lub żądania ściągnięcia w prostym projekcie autoloadera).