PHP ad alanlarını değerlendirme


11

Açık kaynaklı bir PHP projesinin yayın öncesi aşamasındayım, umarım ki diğer geliştiriciler tarafından kendi projelerinde kullanılacak. Proje şu anda ad alanlarını desteklemiyor ve bazı dezavantajlar olmadan aynı teknik faydalara sahip gibi görünen Dir_Subdir_Class'ın ad alanlarını veya PEAR adlandırma kuralını kullanması gerekip gerekmediğini değerlendirmeye çalışıyorum. Dürüst olmak gerekirse, kolay bir seçim değil.

İsim alanlarına karşı bazı hususlar:

  • Projemin benzer projelerden daha basit bir API sağlayarak kendisini farklılaştırmaya çalışmasının yollarından biri. Ad alanları yeni olduğu ve ayrıca PEAR adlandırma kuralından daha karmaşık oldukları için, bunları kod tabanına eklemek projemin kullanımını daha kolay hale getirecektir. Bunları uygulayarak kullanım kolaylığı açısından biraz farklılaşıyorum.
  • Ad alanlarına bazı faydalar görebiliyor olsam da, PEAR adlandırma kuralını kullanan modern bir PHP ürününde çözülmesi gereken bir sorunu çözmediler. Projemi kullanırken çakışmaları adlandırmak, mevcut olmasa bile minimum olmalıdır.
  • Bu makale , uygulamalarının yıldızdan daha az olması nedeniyle ad alanlarını benimsemem için biraz duraklama veriyor.
  • Ben de hiçbir yere gitmeyebilecek bir kunduraya atlamakta tereddüt ediyorum. İsim alanları PHP için yeni bir özellik olduğundan, henüz standart olacağına ikna olmadım.
  • Uyumluluk. Şimdiye kadar yazılan PHP kodlarının neredeyse tamamı yeni bir özellik olduğu için ad alanlarını kullanmaz. Diğer kütüphaneler dönüşüm olmadan uyumsuz olurdu.

Ad alanlarını kullanmak için bazı noktalar:

  • Algı. İsim alanları standart ve en iyi uygulama haline gelirse, projem hızla profesyonel olmayan ve onlar olmadan modası geçmiş olarak görülebilir.
  • Rekabet. Bazı rakip PHP projeleri en son sürümlerinde ad alanlarını kullanmaya başlarken, birçoğu henüz sıçrama yapmadı. Şimdi bunu yapmak, projeme diğer projeler hakkında bilgi verebilir.
  • Geçiş, projenin iki aşamasını desteklemem gereken bir durumdan sonra proje halka açılmadan önce şimdi değiştirirsem daha kolay olurdu.
  • En iyi uygulamaları desteklemek istiyorum ve eğer ad alanları PHP için en iyi uygulama haline geliyorsa, projem bunları kullanmalıdır.

Söyleyebileceğim kadarıyla, şu ya da bu şekilde seçmelisiniz; ikisini de yapamazsın. Düşünmediğim herhangi bir nokta var mı? PHP'nin profesyonel standardı haline gelen isim alanlarına karşı veya ona karşı işaret eden herhangi bir objektif işaret var mı (flamewar yok, lütfen)? Yakında bir karar vermem gerektiğinden, paylaşmak istediğiniz herhangi bir içgörü veya kaynağı takdir ediyorum.

Yanıtlar:


5

PHP'de ad alanlarının kaldığını gösteren iki işaret:

  1. PEAR adlandırma şeması, PEAR2'deki ad alanları lehine terk edildi .
  2. Zend Framework 2.0'ın belirtilen amaçlarından biri , diğer şeylerin yanı sıra ad alanlarını tam olarak kullanarak PHP 5.3 kullanımının bir örneği olmaktır . Bunu, Zend'in ad alanlarına tamamen bağlı olduğunu ve onları desteklemeye ve geliştirmeye devam edeceğine dair güçlü bir gösterge olarak görüyorum (umarım daha iyisi için).

Ad alanlarının mevcut uygulamasının, en azından söylemek gerekirse, tam olarak katılıyorum, ancak bunları kullanmaya karşı argümanlarınız o kadar da sağlam değil. Mevcut formlarında bile, ad alanları şunları sağlar:

  • Daha iyi kod organizasyonu,
  • Adlandırma çarpışmalarından kaçınmak,
  • Sınıflar, fonksiyonlar ve sabitler için bağlam.

PHP ad alanlarına karşı argümanların çoğunun, bir özellik olarak gerçek değerlerine karşı değil, diğer dillerdeki uygulamalarla karşılaştırıldığını unutmayın.


Bağlantılar için +1. Daha iyi kod organizasyonu ve bağlam noktalarını genişletebilir misiniz? Nasıl daha iyi kod organizasyonu sağlar anlamak zor bir zaman var. Çoğu projenin, PEAR adlandırma şemasında kullandığınız gibi, mantıksal dizinlerde gruplandırılmış dosya yapısına 1: 1 sınıfına sadık kalacağı görülüyor. ZF2 bile çoğu durumda aynı dizin ve dosya yapılarını kullanıyor gibi görünüyor, ancak şimdi sadece ad alanlarıyla. Farklıdır, ancak ilk etapta iyi adlandırılmış dizinlerden ve dosyalardan nasıl daha iyi veya daha organize olduğunu görmüyorum.
VirtuosiMedia

Bağlam noktasında da sorun yaşıyorum. Bir şey varsa, ad alanları bağlam eklemek yerine daha özlü bir kodlama stiline sahip olmak için bağlamı kaldırmış gibi görünüyor. Örnek olarak, bir dosyanın derinliklerinde yeni bir sınıf başlatırsam, şimdi sınıf alanının sınıf adından hemen fark edilmesini sağlamak yerine hangi sınıfın hangi sınıf olduğunu anlamak için bildirildiğini bulmam gerekir. Bir şeyi kaçırmadıkça, ad alanlarının daha az ayrıntılı, ancak netlik pahasına olduğu anlaşılıyor.
VirtuosiMedia

@VirtuosiMedia PEAR ve eski ZF adlandırma şemaları ad alanlarını taklit eder , bu nedenle üç noktam da onlar için bir şekilde doğrudur. Ne işaret etmeye çalışıyorum, bu noktalar PHP ad alanlarının geçerli uygulamada doğruysa, o zaman onların küçük snafus onları kullanmak için yeterli değildir. Daha iyi kod organizasyonu ile , çoğunlukla dosyalar arasında, sınıflarınız için mantıklı ve mantıklı bir yapı ve hiyerarşi benimseyerek, isim alanları olmadan elbette mümkün olanı kastediyorum. Ancak ad alanları (ve onları taklit eden şemalar ), her üç noktayı da aynı anda elde etmenize yardımcı olan bir özelliktir.
yannis

Anladım. Açıklama için teşekkürler. Taklit ad alanlarına göre gerçek ad alanları için önemli avantajlar görüyor musunuz ?
VirtuosiMedia

1
@VirtuosiMedia Soru üzerinde oluşturduğunuz ad alanlarını kullanmanın tüm noktaları geçerlidir. Bunun için PHP ad alanlarının, kodunuzun farklı arka planlardaki kodlayıcılara biraz daha doğal hissetmesine yardımcı olacağını, büyük bir projede paha biçilmez olabilecek bir şey ekleyeceğim. Ayrıca taklit ad alanları için bir standart yoktur , bunların çoğu aynıdır, ancak gerçek ad alanlarını kullanmak herkesin aynı şemayı kullanmasını sağlar. BTW Kodunuzu adlandırmak için kullanabileceğiniz bir ad alanı var.
yannis
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.