İşlevlerde PHP global


101

Global anahtar kelimenin faydası nedir ?

Bir yöntemi diğerine tercih etmek için herhangi bir neden var mı?

  • Güvenlik?
  • Verim?
  • Başka herhangi bir şey?

Yöntem 1:

function exempleConcat($str1, $str2)
{
  return $str1.$str2;
}

Yöntem 2:

function exempleConcat()
{
  global $str1, $str2;
  return $str1.$str2;
}

Kullanmak ne zaman mantıklı global?

Benim için tehlikeli görünüyor ... ama bu sadece bilgi eksikliği olabilir. Ben ilgilenen am belgelenmiş (örn kodu, belgelere bağlantı ... örneğiyle) teknik nedenlerden.

Şimdiden teşekkürler!


Ödül

Bu konu hakkında güzel bir genel soru, ben (@Gordon) ek cevaplar almak için bir ödül öneriyorum. Cevabınız benimkiyle aynı fikirde mi yoksa farklı bir bakış açısı mı veriyor önemli değil. Yana globalkonu her şimdi ve sonra çıkageldi, biz bağlantısını için iyi bir "kanonik" cevabını kullanabilirsiniz.


2
şu bağlantıya bir göz atın: stackoverflow.com/questions/1557787 Bu sayfanın sağ alt tarafında ilgili birçok makale var
JohnP

Bu, sorunuzun doğrudan bir cevabı değildir, ancak lütfen bu eski SO sorusunu okuyun .
Ólafur Waage

1
Bu yüzden, küresel yanlısı herhangi bir anahtar kelimeyi okuyamıyorum. 1) Neden burada. 2) İnsanlar neden kullanıyor?
Pascal Qyy

@ G.Qyy Neden var goto? İnsanlar neden kullanıyor?
Kullanmıyorlar

Geçen yılın sonunda (14 Aralık), birisi bu soruya olumsuz oy verdi. Nedenini bilmekle çok ilgileniyorum çünkü negatif olanlar da dahil tüm bakış açıları ilginç. Bu durumda her zamankinden daha fazla! Bununla ilgili herhangi bir ipucu için çok minnettar olacağım.
Pascal Qyy

Yanıtlar:


159

Küreseller kötüdür

Bu, globalanahtar kelime için olduğu kadar, yerel kapsamdan genel kapsama ulaşan diğer her şey için de geçerlidir (statikler, tekler, kayıtlar, sabitler). Onları kullanmak istemezsin. Bir işlev çağrısı dışında herhangi bir şeye dayanmak zorunda olmamalıdır, örneğin

function fn()
{
    global $foo;              // never ever use that
    $a = SOME_CONSTANT        // do not use that
    $b = Foo::SOME_CONSTANT;  // do not use that unless self::
    $c = $GLOBALS['foo'];     // incl. any other superglobal ($_GET, …)
    $d = Foo::bar();          // any static call, incl. Singletons and Registries
}

Bunların tümü, kodunuzu dışarıya bağımlı hale getirecektir. Bu da, bunlardan herhangi birini güvenilir bir şekilde arayabilmeniz için başvurunuzun tam global durumunu bilmeniz gerektiği anlamına gelir. İşlev, bu ortam olmadan var olamaz.

Süper küreselleri kullanmak bariz bir kusur olmayabilir, ancak kodunuzu bir Komut Satırından ararsanız, $_GETveya yok $_POST. Kodunuz bunlardan gelen girdilere dayanıyorsa, kendinizi bir web ortamıyla sınırlamış olursunuz. İsteği bir nesneye soyutlayın ve onun yerine kullanın.

Sabit kodlanmış sınıf adlarının (statik, sabitler) birleştirilmesi durumunda, işleviniz bu sınıf mevcut olmadan da var olamaz. Aynı ad alanından sınıflar söz konusu olduğunda bu daha az sorun olur, ancak farklı ad alanlarından karıştırmaya başladığınızda, karışık bir karmaşa yaratırsınız.

Yeniden kullanım, yukarıdakilerin tümü tarafından ciddi şekilde engellenmektedir. Birim testi de öyle .

Ayrıca, küresel kapsamla eşleştiğinizde işlev imzalarınız yalan söylüyor

function fn()

bir yalancı, çünkü ona hiçbir şey aktarmadan bu işlevi çağırabileceğimi iddia ediyor. Sadece işlev bedenine baktığımda, çevreyi belirli bir duruma ayarlamam gerektiğini öğreniyorum.

İşlevinizin çalışması için bağımsız değişkenler gerekiyorsa, bunları açık hale getirin ve iletin:

function fn($arg1, $arg2)
{
    // do sth with $arguments
}

İmzadan çağrılması gereken şeyi açıkça aktarır. Belirli bir durumda olması çevreye bağlı değildir. Yapmak zorunda değilsin

$arg1 = 'foo';
$arg2 = 'bar';
fn();

Bu, içeri çekme (küresel anahtar kelime) ile içeri itme (argümanlar) meselesidir. Bağımlılıkları ittiğinizde / enjekte ettiğinizde, işlev artık dışarıya güvenmiyor. Bunu yaptığınızda, fn(1)dışarıda bir yerde 1'i tutan bir değişkene sahip olmak zorunda değilsiniz. Fakat $onefonksiyonun içinde global'i çektiğinizde , global kapsamla eşleşir ve onun bir yerde tanımlanan değişkene sahip olmasını beklersiniz. İşlev artık bağımsız değil.

Daha da kötüsü, işlevinizin içindeki küreselleri değiştirirken, kodunuz hızla tamamen anlaşılmaz olacaktır, çünkü işlevleriniz her yerde yan etkilere sahiptir.

Daha iyi bir örnek olmadığından

function fn()
{
    global $foo;
    echo $foo;     // side effect: echo'ing
    $foo = 'bar';  // side effect: changing
}

Ve sonra yaparsın

$foo = 'foo';
fn(); // prints foo
fn(); // prints bar <-- WTF!!

Bunun $foobu üç satırdan değiştiğini görmenin bir yolu yok . Neden aynı işlevi aynı argümanlarla çağırmak birden bire çıktısını değiştirsin veya küresel durumda bir değeri değiştirsin? Bir işlev, tanımlanmış bir Y girişi için X'i yapmalıdır. Her zaman.

Bu, OOP kullanırken daha da ciddileşir, çünkü OOP kapsülleme ile ilgilidir ve genel kapsama ulaşarak kapsüllemeyi bozarsınız. Çerçevelerde gördüğünüz tüm bu Singleton'lar ve Registries, Dependency Injection lehine kaldırılması gereken kod kokularıdır. Kodunuzu ayırın.

Daha fazla kaynak:


10
PHP neden böyle şeyler uygular? Bir yardımcı program var mı? Bir çok insanın her seferinde kullandığı PHP'deki tehlikeli uygulamalar beni her zaman şaşırttı ... Mantıklı nedenler olmadığına inanmak benim için zor!
Pascal Qyy

6
Keşke Globals'ı daha büyük hale getirebilseydiniz .
Kermit

3
Vay canına, sonunda birisi küresellerin neden kötü olduğunu iyi açıkladı ... Öyle olduklarını her zaman duydum ve neden olduğuna dair çok çok özel örnekler gördüm ama bu, genel nedeni için gerçekten iyi ve kapsamlı bir açıklama. +1
Wingblade

Gerçekten geciktim ve ne dediğini anlıyorum, peki ya mysqli bağlantıları? Bunlar her seferinde parametre olarak mı geçmeli yoksa global bir $ bağlantı mı olmalı; gözlerinde izin var mı?
Mave

2
Sabitler dışında haklısın. Uygulamanın bir "durumunu" temsil etmezler ve bunlara bir işlevin içinden başvurmak sorun değildir. İşlev, içeriden bir sabit kullanıyorsa "yalan söylemez". Programcının bir noktada dışarıyı bildiğini ima ettiğine katılıyorum, ama bu sabitin ne olduğu için çok kabul edilebilir bir değiş tokuş. Ayrıca cidden, çok da büyük bir anlaşma değil.
Sebas

35

Karşıt büyük bir neden global, işlevin başka bir kapsama bağlı olduğu anlamına gelmesidir. Bu çok çabuk dağılacak.

$str1 = 'foo';
$str2 = 'bar';
$str3 = exampleConcat();

vs.

$str = exampleConcat('foo', 'bar');

Gerektiren $str1ve $str2işe işlevi çağrısında kapsamında kurulacak gereksiz bağımlılıkları tanıtmak demektir. Bu değişkenleri artık işlevde de yeniden adlandırmadan bu kapsamda ve dolayısıyla diğer tüm kapsamlarda da bu işlevi kullanıyorsunuz. Değişken adlarınızı takip etmeye çalışırken bu kısa süre sonra kaosa dönüşür.

global$dbkaynaklar gibi küresel şeyleri dahil etmek için bile kötü bir model . Orada olacak yeniden adlandırmak istediğiniz zaman gün gelecek $dbama bütün uygulama adına bağlı olduğundan, yapamam.

Değişkenlerin kapsamını sınırlamak ve ayırmak, herhangi bir yarı karmaşık uygulama yazmak için çok önemlidir .


1
Üzgünüm ama neden kesinlikle yeniden adlandırmak isteyeyim $db? Her yerde dolaşan PDO. Bağlantı bilgilerini ayrı ayrı güncelleyebildiğimde neden değiştirilsin?
Casey Dwayne

3
@kcd Çünkü bir gün bağımlılık enjeksiyonunun ne kadar büyük olduğunu anlıyorsunuz ve uygulamanızı yeniden yapılandırmak istiyorsunuz? Çünkü bir gün eşyalarınızı aynı zamanda global bir $dbdeğişken kullanan başka şeylerle bütünleştirmeniz gerekecek mi? Bir gün birim testini keşfedeceğiniz ve bunun için aynı anda birden fazla veritabanı bağlantısını yönetmeniz gerekeceği için mi? Pek çok neden.
deceze

35

Küreseller kaçınılmazdır.

Bu eski bir tartışma, ancak yine de bazı düşüncelerimi eklemek istiyorum çünkü yukarıda bahsedilen cevaplarda onları özlüyorum. Bu cevaplar, küreselin ne kadar fazla olduğunu basitleştiriyor ve soruna hiçbir şekilde çözüm olmayan çözümler sunuyor. Sorun şudur: global bir değişkenle başa çıkmanın ve global anahtar kelimesinin kullanımının doğru yolu nedir? Bunun için önce globalin ne olduğunu incelemeli ve tanımlamalıyız.

Bu Zend koduna bir göz atın - ve lütfen Zend'in kötü yazılmış olduğunu önermediğimi anlayın:

class DecoratorPluginManager extends AbstractPluginManager
{
/**
 * Default set of decorators
 *
 * @var array
 */
protected $invokableClasses = array(
    'htmlcloud' => 'Zend\Tag\Cloud\Decorator\HtmlCloud',
    'htmltag'   => 'Zend\Tag\Cloud\Decorator\HtmlTag',
    'tag'       => 'Zend\Tag\Cloud\Decorator\HtmlTag',
   );

Burada pek çok görünmez bağımlılık var. Bu sabitler aslında sınıflardır. Bu çerçevenin bazı sayfalarında da require_once görebilirsiniz. Require_once küresel bir bağımlılıktır, dolayısıyla harici bağımlılıklar oluşturur. Bu bir çerçeve için kaçınılmazdır. DecoratorPluginManager gibi bir sınıfı, bağlı olduğu çok fazla harici kod olmadan nasıl oluşturabilirsiniz? Çok fazla ekstra olmadan çalışamaz. Zend çerçevesini kullanarak, bir arayüzün uygulamasını hiç değiştirdiniz mi? Bir arayüz aslında küreseldir.

Dünya çapında kullanılan bir diğer uygulama Drupal'dır. Doğru tasarım konusunda çok endişeliler, ancak tıpkı herhangi bir büyük çerçeve gibi, birçok dış bağımlılıkları var. Bu sayfadaki küresellere bir göz atın:

/**
 * @file
 * Initiates a browser-based installation of Drupal.
 */

/**
 * Root directory of Drupal installation.
 */
define('DRUPAL_ROOT', getcwd());

/**
 * Global flag to indicate that site is in installation mode.
 */
define('MAINTENANCE_MODE', 'install');

// Exit early if running an incompatible PHP version to avoid fatal errors.
if (version_compare(PHP_VERSION, '5.2.4') < 0) {
  print 'Your PHP installation is too old. Drupal requires at least PHP 5.2.4. See the     <a     href="http://drupal.org/requirements">system requirements</a> page for more     information.';
  exit;
}

// Start the installer.
require_once DRUPAL_ROOT . '/includes/install.core.inc';
install_drupal();

Giriş sayfasına hiç yönlendirme yazdınız mı? Bu küresel bir değeri değiştiriyor. (Ve sonra, uygulamanızın kötü belgelenmesine iyi bir tepki olarak gördüğüm 'WTF' demiyor musunuz?) Küresellerle ilgili sorun, küresel olmaları değil, anlamlı bir uygulamaya sahip olmak için onlara ihtiyacınız var. Sorun, genel uygulamanın karmaşıklığı ve bunun üstesinden gelinmesi bir kabus haline gelmesidir. Oturumlar globaldir, $ _POST globaldir, DRUPAL_ROOT globaldir, include / install.core.inc 'değiştirilemez bir globaldir. Bu işlevin işini yapmasına izin vermek için gereken herhangi bir işlevin dışında büyük bir dünya vardır.

Gordon'un cevabı yanlıştır, çünkü bir fonksiyonun bağımsızlığını geçersiz kılar ve bir fonksiyonu yalancı olarak adlandırmak durumu aşırı basitleştirir. İşlevler yalan söylemez ve onun örneğine baktığınızda işlev yanlış tasarlanmış - örneği bir hata. (Bu arada, kodun ayrıştırılması gerektiği sonucuna katılıyorum.) Deceze'in yanıtı, durumun uygun bir tanımı değildir. Fonksiyonlar her zaman daha geniş bir kapsamda çalışır ve onun örneği çok basittir. Hepimiz, bu fonksiyonun tamamen yararsız olduğu konusunda hemfikir olacağız, çünkü bir sabit döndürüyor. Bu işlev zaten kötü bir tasarım. Uygulamanın kötü olduğunu göstermek istiyorsanız, lütfen ilgili bir örnekle gelin. Bir uygulama boyunca değişkenleri yeniden adlandırmak, iyi bir IDE'ye (veya bir araca) sahip olmak önemli değildir. Soru, işlevle kapsam farkı değil, değişkenin kapsamı ile ilgilidir. Bir işlevin süreçteki rolünü yerine getirmesi için uygun bir zaman vardır (bu nedenle ilk etapta yaratılmıştır) ve bu uygun zamanda uygulamanın bir bütün olarak işleyişini etkileyebilir, dolayısıyla küresel değişkenler üzerinde de çalışabilir. . Xzyfer'in cevabı, tartışmasız bir ifadedir. Prosedürel işlevleriniz veya OOP tasarımınız varsa, küreseller bir uygulamada olduğu gibi mevcuttur. Bir globalin değerini değiştirmenin sonraki iki yolu temelde aynıdır: dolayısıyla küresel değişkenler üzerinde de çalışıyoruz. Xzyfer'in cevabı, tartışmasız bir ifadedir. Prosedürel işlevleriniz veya OOP tasarımınız varsa, küreseller bir uygulamada olduğu gibi mevcuttur. Bir globalin değerini değiştirmenin sonraki iki yolu temelde aynıdır: dolayısıyla küresel değişkenler üzerinde de çalışıyoruz. Xzyfer'in cevabı, tartışmasız bir ifadedir. Prosedürel işlevleriniz veya OOP tasarımınız varsa, küreseller bir uygulamada olduğu gibi mevcuttur. Bir globalin değerini değiştirmenin sonraki iki yolu temelde aynıdır:

function xzy($var){
 global $z;
 $z = $var;
}

function setZ($var){
 $this->z = $var;
}

Her iki durumda da, belirli bir işlev içinde değiştirilen $ z değeri. Her iki programlama yönteminde de, bu değişiklikleri koddaki bir dizi başka yerde yapabilirsiniz. Global kullanarak $ z'yi her yerde arayabileceğinizi ve orada değiştirebileceğinizi söyleyebilirsiniz. Evet yapabilirsin. Ama yapacak mısın? Ve uyumsuz yerlerde yapıldığında, o zaman bir böcek olarak adlandırılmamalı mı?

Bob Fanger, xzyfer hakkında yorum yapıyor.

O halde herhangi biri herhangi bir şeyi ve özellikle 'global' anahtar kelimesini kullanmalı mı? Hayır, ancak herhangi bir tasarım türü gibi, neye bağlı olduğunu ve neye bağlı olduğunu analiz etmeye çalışın. Ne zaman ve nasıl değiştiğini bulmaya çalışın. Global değerlerin değiştirilmesi, yalnızca her istek / yanıtla değişebilen değişkenlerle gerçekleşmelidir. Yani, teknik uygulamasına değil, yalnızca bir sürecin işlevsel akışına ait olan değişkenlere. Bir URL'nin oturum açma sayfasına yönlendirilmesi, bir sürecin işlevsel akışına, teknik uygulamaya yönelik bir arabirim için kullanılan uygulama sınıfına aittir. İkincisini uygulamanın farklı sürümleri sırasında değiştirebilirsiniz, ancak bunları her istek / yanıtla değiştirmemelisiniz.

Ne zaman globallerle ve global anahtar kelimesiyle çalışmanın bir sorun olduğunu daha iyi anlamak için, bloglar hakkında yazarken Wim de Bie'den gelen bir sonraki cümleyi tanıtacağım: 'Kişisel evet, özel hayır'. Bir fonksiyon, kendi işleyişi adına bir global değişkenin değerini değiştirdiğinde, o zaman global bir değişkenin özel kullanımına ve bir hataya diyeceğim. Ancak genel değişkenin değişikliği, uygulamanın bir bütün olarak düzgün bir şekilde işlenmesi için yapıldığında, kullanıcının oturum açma sayfasına yönlendirilmesi gibi, o zaman bana göre muhtemelen iyi bir tasarım, tanımı gereği kötü değil ve kesinlikle bir anti-desen.

Gordon, deceze ve xzyfer'in yanıtlarına geriye dönüp bakıldığında: Hepsinde örnek olarak 'özel evet' (ve böcekler) var. Bu yüzden küresellerin kullanımına karşı çıkıyorlar. Ben de yapardım. Bununla birlikte, bu cevapta birkaç kez yaptığım gibi 'kişisel evet, özel hayır' örnekleri ile gelmiyorlar.


Drupal kod örneği, küreselleri kullanmaz, sabitleri kullanır. Çok önemli bir fark, bir sabitin tanımlandıktan sonra yeniden tanımlanamamasıdır. Ayrıca sadece fonksiyonları karşılaştıramazsınız xyzve setZ. Birincisi genel durumu değiştirir, ikincisi bir sınıf yöntemidir ve yalnızca çağrıldığı örneğin durumunu değiştirir.
Arjan

@Arjen: Drupal 7.14'te global anahtar kelimesini ararsanız, yüzlerce hit elde edersiniz. Bu, halka açık ayarlayıcılarla ilgili eski bir sorundur: onları halka açıkladıktan sonra değiştirildikleri yeri kontrol edemezsiniz. Bunların hiç kullanılmaması veya özel ilan edilmesi tavsiye edildi, bu nedenle daha sonra eklenemez.
Loek Bergman

@Arjan: Adınızı yazarken yaptığım hatadan dolayı size yanıtımla ilgili herhangi bir bildirim almadınız. Şimdi yapacaksın. :-)
Loek Bergman

@LoekBergman: globaldrupal 7.26'da (en son sürüm) kelime için yaklaşık 400 tıklama var, bu hitlerin bazıları yorumlarda ve bazıları da yıllardır dokunulmamış bir kodda görünüyor. Emin kullandıkları umuyoruz globals drupal 8.
Arjan

@LoekBergman Lütfen ayarlayıcıları ve alıcıları kullanın. Kurmak çok zaman almaz ve kodunuzu kullanan ve belki de sınıflarınızı daha fazla kontrole sahip olacak şekilde genişleten başkalarına izin verir. Bir parametreyi herkese açık hale getirdiğinizde, işte bu. daha sonra gizleme seçeneğiniz yok.
mAsT3RpEE

15

Basitçe söylemek gerekirse global, modern PHP kodu IMHO'da nadiren bir neden vardır ve asla iyi bir neden yoktur . Özellikle PHP 5 kullanıyorsanız ve özellikle Nesneye Yönelik kod geliştiriyorsanız.

Küreseller kodun sürdürülebilirliğini, okunabilirliğini ve test edilebilirliğini olumsuz etkiler. Can globalve birçok kullanımları Dependency Injection ile değiştirilmelidir veya global nesneyi bir parametre olarak iletmelidir.

function getCustomer($db, $id) {
    $row = $db->fetchRow('SELECT * FROM customer WHERE id = '.$db->quote($id));
    return $row;
}

10

PHP'deki işlevler içinde global anahtar sözcük kullanmaktan çekinmeyin. Özellikle küresellerin ne kadar 'kötü' olduğunu ve ne olmadığını tuhaf bir şekilde vaaz eden / bağıran insanları almayın.

Birincisi, çünkü kullandığınız şey tamamen duruma ve soruna bağlıdır ve kodlamada hiçbir şey yapmanın tek bir çözümü / yolu yoktur. Denklemde 'kötü' gibi tanımlanamayan, öznel, dinsel sıfatların yanlışlığını tamamen bir kenara bırakırsak.

Konuşma konusu olan mesele :

Wordpress ve ekosistemi, işlevlerinde global anahtar sözcük kullanır. OOP kodu olun veya OOP değil.

Ve şu an itibariyle Wordpress, internetin temelde% 18.9'u ve Reuters'tan Sony'ye, NYT'ye ve CNN'e kadar sayısız devin devasa megazitlerini / uygulamalarını çalıştırıyor.

Ve bunu iyi yapıyor.

İşlevler içinde global anahtar kelimenin kullanımı, Wordpress'i devasa ekosistemi göz önüne alındığında gerçekleşebilecek MASSIVE şişkinlikten kurtarır. Her işlevin başka bir eklentiden, çekirdekten ve geri dönen herhangi bir değişkeni sorduğunu / ilettiğini hayal edin. Eklenti bağımlılıkları ile eklendi, bu bir değişken kabusu veya değişkenler olarak aktarılan bir dizi kabusu ile sonuçlanır. İzlenecek bir Cehennem, hata ayıklanması gereken bir cehennem, geliştirilecek bir cehennem. Kod şişkinliği ve değişken şişkinlik nedeniyle mantıksız bir şekilde büyük bellek ayak izi. Yazması da daha zor.

Wordpress'i, ekosistemini, uygulamalarını ve bu kısımlarda olup biteni eleştiren insanlar olabilir.

Anlamsız, çünkü bu ekosistem neredeyse tüm internetin% 20'sini oluşturuyor. Görünüşe göre iş YAPAR, işini yapar ve daha fazlasını yapar. Bu, global anahtar kelime için de aynı olduğu anlamına gelir.

Bir başka güzel örnek de "iframe'ler kötüdür" köktenciliktir. On yıl önce iframe kullanmak sapkınlıktı. Ve internette onlara karşı vaaz veren binlerce insan vardı. Sonra facebook geliyor, sonra sosyal geliyor, şimdi iframe'ler 'beğen' kutularından kimlik doğrulamasına ve işte her yerde - herkes sussun. Hâlâ susmayanlar var - haklı ya da haksız olarak. Ama biliyorsunuz, bu tür görüşlere rağmen hayat devam ediyor ve on yıl önce iframe'lere karşı vaaz verenler bile şimdi bunları çeşitli sosyal uygulamaları tek bir kelime söylemeden kuruluşlarının kendi uygulamalarına entegre etmek için kullanmak zorunda kalıyorlar.

......

Coder Fundamentalizm, çok çok kötü bir şeydir. Aramızdaki küçük bir yüzde, bilgi teknolojisindeki sürekli değişime ve rekabete, zamana, bütçeye ve diğer hususlara ilişkin getirdiği baskılara dayanmak için yeterli nüfuza sahip sağlam yekpare bir şirkette rahat bir işe sahip olabilir ve bu nedenle pratik yapabilir. köktendincilik ve algılanan "kötülüklere" veya "mallara" sıkı sıkıya bağlılık. Eski çağları anımsatan rahat pozisyonlar, işgalciler genç de olsa bunlar.

Ancak çoğunluk için BT dünyası, açık fikirli ve pratik olmaları gereken sürekli değişen bir dünyadır. Köktendinciliğe yer yoktur, bilgi teknolojisinin ön saflarında 'kötülük' gibi çirkin anahtar kelimeleri bir kenara bırakın.

Yakın, orta ve uzun vadeli gelecek için uygun değerlendirmelerle, ELİNİZDEKİ problem için en mantıklı olanı kullanın. Herhangi bir özelliği veya yaklaşımı kullanmaktan çekinmeyin, çünkü herhangi bir kodlayıcı alt kümesi arasında, ona karşı yaygın bir ideolojik düşmanlığı vardır.

Senin işini yapmayacaklar. Olacaksın. Koşullarınıza göre hareket edin.


3
Anti-köktencilik için +1, ama sadece "birçok insan kullanıyor / işe yarıyor / vs" demek sadece bir "tartışma reklamı populum", temel bir safsatadır. insanların çoğunun bir şeyi düşünmesi veya yapması gerçeği, haklı olduklarını kanıtlamaz! bir kalabalığın içinde, eğer bir tehlike ortaya çıkarsa, insanların çoğu aptalca şeyler yapacak ve bazıları başkaları tarafından ezilerek ölecektir. Sırf yangından kaçmak için çekilirse açılan bir kapıyı kesinlikle itmeleri gerektiğini düşündükleri için bu beş yaşındaki küçük kızın yüzüne ayaklarını basmakta haklılar mı? Sanmıyorum…
Pascal Qyy

1
Elbette çoğunluğun bir şey yapması kendi başına hiçbir şeyi doğrulamaz. ancak durum yazılımdır. ve eğer çoğunluk bunu yapıyorsa ve bu insanlar tarafından oluşturulan uygulamaların ve hizmetlerin çoğu iyi durumda ise (diğerleri için wordpress), bu onların kullanılabileceği anlamına gelir.
unity100

7

Bence herkes küresellerin olumsuz yönleri hakkında oldukça fazla açıklama yaptı. Bu yüzden pozitifleri ve küresellerin doğru kullanımı için talimatları ekleyeceğim:

  1. Küresellerin temel amacı, işlevler arasında bilgi paylaşmaktı. sınıf gibi bir şey olmadığında, php kodu bir dizi işlevden oluşuyordu. Bazen işlevler arasında bilgi paylaşmanız gerekir. Tipik olarak küresel, verileri küresel hale getirerek bozulma riski ile bunu yapmak için kullanılırdı.

    Şimdi, bazı mutlu go lucky simpleton bağımlılık enjeksiyonu hakkında bir yorum yapmaya başlamadan önce, size örnek gibi bir işlevin kullanıcısının işlevin get_post(1)tüm bağımlılıklarını nasıl bildiğini sormak istiyorum . Ayrıca bağımlılıkların
    sürümden sürüme ve sunucudan sunucuya farklılık gösterebileceğini unutmayın . Bağımlılık ekleme ile ilgili temel sorun, bağımlılıkların önceden bilinmesidir. Bunun mümkün olmadığı veya istenmeyen küresel değişkenlerin bu amaca ulaşmanın tek yolu olduğu bir durumda.

    Sınıfın oluşturulması nedeniyle, artık ortak işlevler bir sınıfta kolayca gruplandırılabilir ve verileri paylaşabilir. Arabulucular gibi uygulamalar aracılığıyla ilgisiz nesneler bile bilgi paylaşabilir. Bu artık gerekli değil.

  2. Globals için başka bir kullanım konfigürasyon amaçlıdır. Çoğunlukla herhangi bir otomatik yükleyici yüklenmeden, veritabanı bağlantıları yapılmadan vb. Önce bir komut dosyasının başlangıcında.

    Kaynakların yüklenmesi sırasında, globaller verileri yapılandırmak için kullanılabilir (yani, kütüphane dosyalarının bulunduğu yerde hangi veritabanının kullanılacağı, sunucunun url'si vb.). Bunu yapmanın en iyi yolu, define()işlevin kullanılmasıdır, çünkü bu değerler sık ​​sık değişmez ve kolaylıkla bir yapılandırma dosyasına yerleştirilebilir.

  3. Küreseller için son kullanım, ortak verileri (yani CRLF, IMAGE_DIR, IMAGE_DIR_URL), insan tarafından okunabilir durum bayraklarını (yani ITERATOR_IS_RECURSIVE) tutmaktır. Burada globaller, uygulama genelinde kullanılması amaçlanan bilgileri depolamak için kullanılır ve bunların değiştirilmesine ve bu değişikliklerin uygulama genelinde görünmesine olanak tanır.

  4. Tekil kalıp, php4 sırasında, bir nesnenin her bir örneği bellek aldığında, php'de popüler hale geldi. Singleton, bir nesnenin yalnızca bir örneğinin oluşturulmasına izin vererek ram tasarrufuna yardımcı oldu. Referanslardan önce bağımlılık enjeksiyonu bile kötü bir fikir olurdu.

    PHP 5.4+ 'den gelen nesnelerin yeni php uygulaması, bu sorunların çoğunu halleder, nesneleri çok az veya hiç ceza almadan güvenli bir şekilde geçirebilirsiniz. Bu artık gerekli değil.

    Tekil kullanım için başka bir kullanım, bir nesnenin yalnızca bir örneğinin aynı anda olması gereken, komut dosyası yürütülmeden önce / sonra var olabilen ve bu nesnenin farklı komut dosyaları / sunucular / diller arasında paylaşıldığı özel örnektir. çözüm oldukça iyi.

Sonuç olarak, eğer 1, 2 veya 3 konumundaysanız, o zaman global kullanmak mantıklı olacaktır. Ancak diğer durumlarda Yöntem 1 kullanılmalıdır.

Küresellerin kullanılması gereken diğer örnekleri güncellemekten çekinmeyin.


6

Global anahtar sözcüğünü kullanarak bir concat işlevi yapmanın bir anlamı yoktur.

Bir veritabanı nesnesi gibi global değişkenlere erişmek için kullanılır.

Misal:

function getCustomer($id) {
  global $db;
  $row = $db->fetchRow('SELECT * FROM customer WHERE id = '.$db->quote($id));
  return $row;
}

Singleton modelinde bir varyasyon olarak kullanılabilir


"hiçbir anlam ifade etmiyor" - aslında öyle: bir örnek OOP kullanmadan bir arama tablosu uygulayacaktır.
Nir Alfasi
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.