WordPress'te PHP Ad Alanları - Mantıksız Bir Kılavuz

PHP ad alanları neredeyse on yaşında. Evet, on yıl geçti (ve evet, yaşlanıyorsunuz). PHP v5.3'ün piyasaya sürülmesinin üzerinden on yıl geçmesine rağmen, birçok geliştirici hala ad alanları hakkında temel bir anlayışa sahip değil. Gerçeği söylemek gerekirse, WordPress ad alanlarını kullanmaz, bu nedenle “ yalnızca WordPress ile çalışıyorsanız ad alanlarını nasıl kullanacağınızı bilmenize gerek yoktur .” Bir ad alanı ninjası olmanıza gerek yok, ancak temel bilgileri kavramak basittir ve size iyi gelir.

Ad alanı desteği olmadığında – bir önek kullanın

Uzun, uzun bir süre PHP yerel ad alanı desteğine sahip değildi. Bu nedenle WordPress ve diğer birçok büyük kod tabanı yerel ad alanları kullanmaz. Gerektiğinde ortalıkta yoktular, bu yüzden önekler kullanılıyor.

Ad alanı önemlidir çünkü write_to_log() işlevinizin başka bir kod parçası tarafından tanımlanmadığından emin olur. Genel kapsamdaki her şeyin ad çakışmasını önlemek için bir önek gerekir, böylece işlev awesome_project_write_to_log() olur ve diğer tüm işlevler ve değişkenler de awesome_project_ önekini alır. Basit? Bu! Güzel? Tam olarak değil.

Statik yöntemler kapsülleme gibi bu yaklaşıma bazı alternatifler vardır. Tüm işlevlerinizi bir sınıfa sarar ve bunları statik yöntemler olarak bildirirsiniz. Ardından my_function() çağırmak yerine My_Class::my_function() . Daha iyi? Biraz, ama yine de uygun ad alanı değil.

Ad alanının birden çok kod parçasının (veya isterseniz paketin) aynı sınıf ve işlev adlarını çakışmadan kullanmasına nasıl izin verdiğini görelim. Veya PHP kılavuzunun dediği gibi - kod kapsüllemesini nasıl etkinleştirdiklerini. Dosyalar ve klasörlerle olan benzerlikleri de yerinde – birçok yönden ad alanları tıpkı klasörler gibi davranıyor, bu yüzden kılavuzdan kopyalayacağım/yapıştıracağım;

Ad alanlarını bildirme – ilk satırı hatırlayın

namespace anahtar sözcüğü dosyadaki ilk kod satırı olmalıdır (yorumları ve PHP dışı içeriği saymaz). Ad alanları yalnızca sınıfları, arabirimleri, işlevleri ve sabitleri etkiler. Değişkenleri etkilemezler. Aynı ad alanını birden çok dosyada tanımlayarak kodu birden çok dosyaya bölmenize olanak tanır. Alt ad alanları, klasörlerde olduğu gibi ad alanlarında bir ters eğik çizgi – namespace myproject\level1\level2 kullanarak bir hiyerarşi tanımlamaya izin verir. Bunlar, ad alanlarını bildirmek için temel ve neredeyse tüm kurallardır.

// 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
}

Mümkün olsa da, birden çok ad alanını tek bir dosyada birleştirmemenizi şiddetle tavsiye ederim. İnanın bana, er ya da geç bunu yaptığınızı unutacaksınız ve ardından 2 dakikalık bir hatayı ayıklamak iki saatinizi alacak. Ancak, gerekirse, işte sözdizimi.

// 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();
}

Ad alanlarını kullanma – klasörleri hatırlayın

Daha önce de söylediğim gibi – ad alanları klasörlere son derece benzer. foo.txt dosyasının geçerli klasörünüzde olduğunu varsayarsak; basit bir foo.txt ile başvurabilirsiniz. foo.txt dosyasının bulunduğu klasörün bir düzey üstündeyseniz, göreceli bir yol ../foo.txt veya mutlak bir /folder1/folder2/foo.txt kullanmanız gerekir. Fantezi bir şey yok. Ad alanları aynı paradigmayı kullanır.

// 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;

PHP kılavuzundaki use anahtar sözcüğüne bir göz atın – örnekler harika. Diğer PHP ad alanlarından geçerli ad alanına kod almak veya bir takma adla harici (tam nitelikli) bir ada başvurmak için bir yol sağlar.

Evet, ad alanlarına ihtiyacınız var ve bunları kullanmalısınız

WordPress'in kaynağına baktığınızda çok açık olduğu gibi – ad alanlarını kullanmanız gerekmez, ancak bazı ad alanı yöntemleri kullanmanız gerekir. WP'nin durumunda wp_ ile ön ek. Öyleyse zaten yapıyorsak neden düzgün yapmıyoruz?

PHP'deki ad alanları, herhangi bir geliştirme iş akışına kolayca entegre olur. Otomatik yüklemeyi, dosya adlandırmayı kolaylaştırır ve genel olarak kodu daha temiz hale getirir. Eski kodu yeniden düzenlemek hiçbir zaman popüler bir görev değildir (kodlama dili ne olursa olsun), bu yüzden size devam etmenizi ve sadece ad alanlarını kullandığınızı söyleyebilmeniz için çalışan bir 2 MB projeyi yeniden düzenlemenizi söylemeyeceğim. Ancak, yeni projeler üzerinde çalışırken ad alanlarını kullanmanız konusunda ısrar edeceğim. Yakında kendine teşekkür edeceksin.