function foo () {
global $var;
// rest of code
}
Küçük PHP projelerimde genellikle yordamsal yoldan gidiyorum. Genelde sistem konfigürasyonunu içeren bir değişkenim var ve bu değişkene bir fonksiyonda erişmeye ihtiyaç duyduğumda var global $var;.
Bu kötü bir uygulama mı?
Yanıtlar:
İnsanlar diğer dillerdeki küresel değişkenler hakkında konuştuğunda, bu PHP'de yaptıklarından farklı bir anlama gelir. Bunun nedeni değişkenlerin PHP'de gerçekten küresel olmamasıdır . Tipik bir PHP programının kapsamı bir HTTP isteğidir. Oturum değişkenleri aslında PHP "global" değişkenlerinden daha geniş bir kapsama sahiptir, çünkü bunlar genellikle birçok HTTP isteğini kapsar.
Genellikle (her zaman?) Aşağıdaki gibi yöntemlerde üye işlevleri çağırabilirsiniz preg_replace_callback():
preg_replace_callback('!pattern!', array($obj, 'method'), $str);
Daha fazlası için geri aramalara bakın .
Mesele şu ki, nesneler PHP'ye cıvatalanmış ve bazı şekillerde bazı garipliklere yol açıyor.
Standartları veya farklı dillerden yapıları PHP'ye uygulamakla fazla ilgilenmeyin. Diğer bir yaygın tuzak, nesne modellerini her şeyin üzerine yapıştırarak PHP'yi saf bir OOP diline dönüştürmeye çalışmaktır.
Her şey gibi, "global" değişkenler, prosedürel kod, belirli bir çerçeve ve OOP kullanın çünkü bu mantıklıdır, bir sorunu çözer, yazmanız gereken kod miktarını azaltır veya onu daha sürdürülebilir ve anlaşılır hale getirir, çünkü düşündüğünüz için değil malısın.
array ($obj, 'callbackMethod')Çağrılarda formun geri aranmasını kullanamaz preg_replace_callback()mısınız? (Biliyorum, bu OOP
Global değişkenler dikkatli kullanılmazlarsa problemlerin bulunmasını zorlaştırabilir. Diyelim ki bir php betiği talep ettiniz ve bazı işlevlerde bulunmayan bir dizinin dizinine erişmeye çalıştığınızı söyleyen bir uyarı alıyorsunuz.
Erişmeye çalıştığınız dizi işlev için yerelse, orada bir hata yapıp yapmadığınızı görmek için işlevi kontrol edin. Bu, işleve bir girişte sorun olabilir, bu nedenle işlevin çağrıldığı yerleri kontrol edin.
Ancak bu dizi global ise, bu global değişkeni kullandığınız tüm yerleri kontrol etmeniz gerekir ve sadece bu değil, global değişkene bu referanslara hangi sırayla erişildiğini bulmanız gerekir.
Bir kod parçasında global bir değişkeniniz varsa, bu kodun işlevselliğini izole etmeyi zorlaştırır. Neden işlevselliği izole etmek istersiniz? Böylece onu test edebilir ve başka bir yerde yeniden kullanabilirsiniz. Eğer bir kodunuz varsa, test etmeniz gerekmiyorsa ve tekrar kullanmanız gerekmiyorsa, o zaman global değişkenleri kullanmak iyidir.
cletus'a katılıyorum. iki şey eklerdim:
saygılarımla, don
$DB = 'foo';
Tecrübe, üniversite diplomaları ve yazılım mühendisliğine kim karşı çıkabilir? Ben değilim. Sadece nesne yönelimli tek sayfalı PHP uygulamaları geliştirirken, ad alanı çarpışmaları konusunda endişelenmeden her şeyi sıfırdan oluşturabileceğimi bildiğimde daha çok eğlenirim. Sıfırdan inşa etmek, birçok insanın artık yapmadığı bir şey. İlgilenmeleri gereken bir işi, son tarihi, ikramiyesi veya itibarı vardır. Bu türler, yüksek riskli önceden oluşturulmuş çok fazla kod kullanma eğilimindedir ve küresel değişkenleri kullanma riskini hiçbir şekilde alamazlar.
Global değişkenleri kullanmak, bir programın yalnızca global alanında kullanılsalar bile kötü olabilir, ancak sadece eğlenmek ve bir şeyler yapmak isteyenleri unutmayalım .
Bu, global ad alanında birkaç değişken (<10) kullanmak anlamına geliyorsa, bu yalnızca bir programın global alanında kullanılır, öyle olsun. Evet, evet, MVC, bağımlılık enjeksiyonu, harici kod, blah, blah, blah, blah. Ancak, kodunuzun% 99.99'unu ad alanlarına ve sınıflara dahil ettiyseniz ve harici kod korumalı alana alınmışsa, global bir değişken kullanırsanız dünya sona ermeyecektir (tekrar ediyorum, dünya sona ermeyecektir).
Genel olarak, küresel değişkenleri kullanmanın kötü bir uygulama olduğunu söylemem . Bir programın küresel alanı dışında küresel değişkenler (bayraklar ve benzeri) kullanmanın sorun yarattığını ve (uzun vadede) kötü tavsiye edildiğini söyleyebilirim , çünkü durumlarının izini oldukça kolay kaybedebilirsiniz. Ayrıca, ne kadar çok öğrenirseniz, küresel değişkenlere o kadar az bağımlı olacağınızı söyleyebilirim, çünkü bunların kullanımıyla ilişkili hataları bulmanın "neşesini" deneyimlemiş olacaksınız. Bu tek başına sizi aynı sorunu çözmek için başka bir yol bulmaya teşvik edecektir. Tesadüfen, bu PHP çalışanlarını ad alanlarının ve sınıfların (statik üyeler, vb.) Nasıl kullanılacağını öğrenme yönüne itme eğilimindedir.
Bilgisayar bilimi alanı çok geniştir. Herkesi bir şeyi kötü olarak nitelendirdiğimiz için yapmaktan korkutursak , etiketin arkasındaki mantığı gerçekten anlamanın eğlencesini kaybederler.
Gerekirse global değişkenleri kullanın, ancak sorunu onlarsız çözüp çözemeyeceğinizi görün. Çarpışmalar, testler ve hata ayıklama, yalnızca sorunun bir açıklamasını değil, sorunun gerçek doğasını yakından anladığınızda daha fazla anlama gelir.
Biten SO Documentation Beta'dan yeniden yayınlandı
Bu sorunu aşağıdaki sözde kod ile gösterebiliriz
function foo() {
global $bob;
$bob->doSomething();
}
Buradaki ilk sorunuz apaçık bir soru
Nereden
$bobgeldi
Kafan mı karıştı? İyi. Küresellerin neden kafa karıştırıcı olduğunu ve kötü bir uygulama olarak kabul edildiğini yeni öğrendiniz. Bu gerçek bir program olsaydı, bir sonraki eğlenceniz, tüm örneklerin izini sürmek $bobve doğru olanı bulmanızı ummaktır ( $bobher yerde kullanılırsa bu daha da kötüleşir ). Daha da kötüsü, başka biri gidip tanımlarsa $bob(veya bu değişkeni unutup yeniden kullanırsanız) kodunuz kırılabilir (yukarıdaki kod örneğinde, yanlış nesneye sahip olmak veya hiç nesneye sahip olmamak, ölümcül bir hataya neden olur). Neredeyse tüm PHP programları, include('file.php');sizin işiniz gibi kodu kullandığından, kodun bu şekilde korunması, eklediğiniz dosya sayısı arttıkça katlanarak zorlaşır.
Küresellerden nasıl kaçınırız?
Küresellerden kaçınmanın en iyi yolu, Bağımlılık Enjeksiyonu adı verilen bir felsefedir . Bu, ihtiyaç duyduğumuz araçları işleve veya sınıfa geçirdiğimiz yerdir.
function foo(\Bar $bob) {
$bob->doSomething();
}
Bunu anlamak ve sürdürmek çok daha kolay. Nerede $bobkurulduğuna dair hiçbir tahmin yoktur çünkü arayan kişi bunu bilmekten sorumludur (bilmemiz gereken şeyi bize iletir). Daha da iyisi, iletileni kısıtlamak için tür bildirimlerini kullanabiliriz . Yani bunun $bobya Barsınıfın bir örneği ya da bir alt sınıfın örneği Barolduğunu biliyoruz, yani o sınıfın yöntemlerini kullanabileceğimizi biliyoruz. Standart bir otomatik yükleyici ile birleştirildiğinde (PHP 5.3'ten beri mevcuttur), şimdi nerede Bartanımlandığını izleyebiliriz . PHP 7.0 veya üstü, skaler türleri de ( intveya gibi string) kullanabileceğiniz genişletilmiş tür bildirimlerini içerir .
$bob = Bar::instance();zaman ihtiyacın olduğu anda yapabilirsin .
Gibi:
global $my_global;
$my_global = 'Transport me between functions';
Equals $GLOBALS['my_global']
kötü bir uygulamadır (Wordpress gibi $pagenow) ... hmmm
Şunu düşünün:
$my-global = 'Transport me between functions';
PHP hatasıdır Ama:
$GLOBALS['my-global'] = 'Transport me between functions';
olduğu DEĞİL hata, hypens çatışma olmayacak ile "ortak" kullanıcı gibi değişkenleri ilan $pagenow. Ve BÜYÜK HARF kullanmak, kullanımda olan, kodda kolayca tespit edilebilen veya dosyalarda bulmayla izlenen bir süper küresel olduğunu gösterir.
Tek bir çözüm için her şeyin sınıflarını oluşturmakta tembelysem, kısa çizgi kullanıyorum, örneğin:
$GLOBALS['PREFIX-MY-GLOBAL'] = 'Transport me ... ';
Ancak daha geniş bir kullanım durumunda kullanıyorum dizi olarak BİR global :
$GLOBALS['PREFIX-MY-GLOBAL']['context-something'] = 'Transport me ... ';
$GLOBALS['PREFIX-MY-GLOBAL']['context-something-else']['numbers'][] = 'Transport me ... ';
İkincisi benim için, her seferinde bazı verileri "önbelleğe almak" için tekli sınıflarla dağınıklık yerine "kola ışık" hedefleri veya kullanımıyla ilgili iyi bir uygulama . Burada yanlışsam veya aptalca bir şey kaçırırsam lütfen yorum yapın ...