Przestrzenie nazw PHP w WordPressie — przewodnik bez bzdur

Przestrzenie nazw PHP mają prawie dziesięć lat. Tak, minęła dekada (i tak, starzejesz się). Pomimo dekady, która minęła od czasu wydania PHP v5.3, wielu programistów wciąż nie ma podstawowej wiedzy na temat przestrzeni nazw. Prawdę mówiąc, WordPress nie używa przestrzeni nazw , więc „ nie musisz wiedzieć, jak używać przestrzeni nazw, jeśli pracujesz tylko z WordPressem ”. Nie musisz być ninja przestrzeni nazw, ale opanowanie podstaw jest proste i dobrze ci pomaga.

Gdy nie ma obsługi przestrzeni nazw – użyj prefiksu

Przez długi czas PHP nie posiadało natywnej obsługi przestrzeni nazw. Dlatego WordPress i wiele innych dużych baz kodu nie używa natywnych przestrzeni nazw. Nie było ich w pobliżu, gdy były potrzebne, więc używane są przedrostki.

Przestrzenie nazw są ważne, ponieważ zapewniają, że funkcja write_to_log() nie została już zdefiniowana przez inny fragment kodu. Aby uniknąć kolizji nazw, wszystko w zasięgu globalnym wymaga prefiksu, aby funkcja stała się awesome_project_write_to_log() , a wszystkie inne funkcje i zmienne również otrzymały prefiks awesome_project_ . Jedyny? To jest! Piękny? Nie dokładnie.

Istnieje kilka alternatyw dla tego podejścia, takich jak enkapsulacja metod statycznych. Opakowujesz wszystkie swoje funkcje w klasę i deklarujesz je jako metody statyczne. Następnie zamiast wywoływania my_function() wywołujesz My_Class::my_function() . Lepszy? Trochę, ale nadal nie ma odpowiedniej przestrzeni nazw.

Zobaczmy, jak przestrzeń nazw pozwala wielu fragmentom kodu (lub pakietom, jeśli chcesz) używać tych samych nazw klas i funkcji bez konfliktów. Albo jak mówi instrukcja PHP – jak umożliwiają enkapsulację kodu. Ich analogia do plików i folderów jest również na miejscu – pod wieloma względami przestrzenie nazw zachowują się jak foldery, więc skopiuję/wkleję z podręcznika;

Deklarowanie przestrzeni nazw – zapamiętaj pierwszą linię

Przestrzeń namespace słów kluczowych musi być pierwszym wierszem kodu w pliku (nie licząc komentarzy i treści innych niż PHP). Przestrzenie nazw wpływają tylko na klasy, interfejsy, funkcje i stałe. Nie wpływają na zmienne. Możesz zdefiniować tę samą przestrzeń nazw w wielu plikach, co pozwala podzielić kod na wiele plików. Podprzestrzenie nazw pozwalają zdefiniować hierarchię w przestrzeniach nazw podobnie jak w folderach za pomocą odwrotnego ukośnika – namespace myproject\level1\level2 . To są podstawowe i prawie wszystkie zasady deklarowania przestrzeni nazw.

// file-A.php contains a function under the myCompany\PackageA namespace
namespace myCompany\PackageA;
 
function do_something() {
  // do things
}

// file-B.php contains a function with the same name
// but under a different namespace
namespace myCompany\PackageB;
 
function do_something() {
  // do things
}

Chociaż to możliwe, zdecydowanie odradzam łączenie wielu przestrzeni nazw w jeden plik. Zaufaj mi, prędzej czy później zapomnisz, że to zrobiłeś, a debugowanie 2-minutowego błędu zajmie dwie godziny. Jeśli jednak musisz, oto składnia.

// do not put multiple namespace declarations into the same file
// but if you must, here's the syntax

namespace MyFirstProject {
  const CONST = true;
  class Connection { /* ... */ }
  function connect() { /* ... */  }
}

namespace MySecondProject {
  const CONST = true;
  class Connection { /* ... */ }
  function connect() { /* ... */  }
}

// any code after this has to go in the global namespace
namespace {
  $some_var = 1;
  function_in_global_namespace();
}

Korzystanie z przestrzeni nazw – pamiętaj o folderach

Jak już powiedziałem – przestrzenie nazw są niezwykle podobne do folderów. Zakładając, że plik foo.txt znajduje się w bieżącym folderze; możesz odwołać się do niego za pomocą prostego pliku foo.txt . Jeśli jesteś poziom wyżej niż folder z plikiem foo.txt , musisz użyć ścieżki względnej ../foo.txt lub bezwzględnej /folder1/folder2/foo.txt . Nic fajnego. Przestrzenie nazw używają tego samego paradygmatu.

// remember after declaring a namespace
// all our code is in it; like when you're working in a folder
namespace mycompany\project;

function foo() {}
class foo {
  static function staticmethod() {}
}

// resolves to mycompany\project\foo() because of line #3
foo();

// likewise, resolves to mycompany\project\foo::staticmethod()
foo::staticmethod();

// constant are affected by namespaces too
// so we're working with mycompany\project\FOO
echo FOO;

// this is a relative path
// resolves to mycompany\project\subnamespace\foo()
subnamespace\foo();

// static methods are no different
// mycompany\project\subnamespace\foo::staticmethod()
subnamespace\foo::staticmethod();
                                 
// a full namespace path starts with a backslash
// it resolves exactly to what it says it does
\otherNamespace\Bar\foo();

// again same thing for a constant, full path nothing magical
echo \otherNamespace\Bar\FOO;

Spójrz na słowo kluczowe use w podręczniku PHP – przykłady są świetne. Zapewnia sposób importowania kodu z innych przestrzeni nazw PHP do bieżącej przestrzeni nazw lub odwoływania się do zewnętrznej (w pełni kwalifikowanej) nazwy za pomocą aliasu.

Tak, potrzebujesz przestrzeni nazw i powinieneś ich używać

Jak widać, patrząc na źródło WordPressa – nie musisz używać przestrzeni nazw, ale musisz użyć jakiejś metody przestrzeni nazw. Prefiks z wp_ w przypadku WP. Więc jeśli już to robimy, dlaczego nie zrobić tego właściwie?

Przestrzenie nazw w PHP łatwo integrują się z dowolnym przepływem pracy programistycznej. Ułatwiają automatyczne ładowanie, nazewnictwo plików i ogólnie sprawiają, że kod jest czystszy. Refaktoryzacja starego kodu nigdy nie jest popularnym zadaniem (bez względu na język kodowania), więc nie zamierzam ci mówić, żebyś kontynuował i refaktoryzował działający projekt o wielkości 2 MB tylko po to, aby można było powiedzieć, że używasz przestrzeni nazw. Jednak będę nalegał, abyś używał przestrzeni nazw podczas pracy nad nowymi projektami. Wkrótce sobie podziękujesz.