Tiện ích của từ khóa toàn cầu là gì?

Có bất kỳ lý do nào để thích phương pháp này hơn phương pháp khác không?

• Bảo vệ?
• Hiệu suất?
• Còn gì nữa không?

Phương pháp 1:

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

Phương pháp 2:

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

Khi nào nó có ý nghĩa để sử dụng global?

Đối với tôi, nó có vẻ nguy hiểm ... nhưng nó có thể chỉ là do thiếu kiến ​​thức. Tôi quan tâm đến tài liệu (ví dụ như với ví dụ về mã, liên kết đến tài liệu ...) lý do kỹ thuật.

Cảm ơn trước!

Tiền thưởng

Đây là một câu hỏi chung rất hay về chủ đề này, tôi (@Gordon) đang đưa ra một khoản tiền thưởng để có thêm câu trả lời. Cho dù câu trả lời của bạn đồng ý với tôi hay đưa ra một quan điểm khác không quan trọng. Vì globalchủ đề này thỉnh thoảng xuất hiện, chúng tôi có thể sử dụng một câu trả lời "chuẩn" để liên kết đến.

Globals là ác

Điều này đúng cho globaltừ khóa cũng như mọi thứ khác tiếp cận từ phạm vi cục bộ đến phạm vi toàn cục (tĩnh, đơn lẻ, đăng ký, hằng số). Bạn không muốn sử dụng chúng. Một lệnh gọi hàm không cần phải dựa vào bất cứ thứ gì bên ngoài, ví dụ:

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
}

Tất cả những điều này sẽ làm cho mã của bạn phụ thuộc vào bên ngoài. Có nghĩa là, bạn phải biết trạng thái toàn cầu đầy đủ mà ứng dụng của bạn đang ở trước khi bạn có thể tin cậy gọi bất kỳ trạng thái nào trong số này. Chức năng không thể tồn tại nếu không có môi trường đó.

Việc sử dụng superglobals có thể không phải là một lỗ hổng rõ ràng, nhưng nếu bạn gọi mã của mình từ Dòng lệnh, bạn không có $_GEThoặc $_POST. Nếu mã của bạn dựa vào đầu vào từ những thứ này, bạn đang tự giới hạn mình trong môi trường web. Chỉ cần trừu tượng hóa yêu cầu thành một đối tượng và sử dụng nó thay thế.

Trong trường hợp ghép các tên lớp mã hóa cứng (tĩnh, hằng số), hàm của bạn cũng không thể tồn tại nếu không có lớp đó. Đó là ít vấn đề hơn khi đó là các lớp từ cùng một không gian tên, nhưng khi bạn bắt đầu trộn từ các không gian tên khác nhau, bạn đang tạo ra một mớ hỗn độn.

Việc sử dụng lại bị cản trở bởi tất cả những điều trên. Kiểm thử đơn vị cũng vậy .

Ngoài ra, các chữ ký chức năng của bạn đang nằm khi bạn kết hợp với phạm vi toàn cầu

function fn()

là một kẻ nói dối, bởi vì nó tuyên bố rằng tôi có thể gọi hàm đó mà không cần chuyển bất cứ thứ gì cho nó. Chỉ khi tôi nhìn vào cơ quan chức năng, tôi mới biết mình phải đặt môi trường vào một trạng thái nhất định.

Nếu hàm của bạn yêu cầu các đối số chạy, hãy làm cho chúng rõ ràng và chuyển chúng vào:

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

chuyển tải rõ ràng từ chữ ký những gì nó yêu cầu được gọi. Nó không phụ thuộc vào môi trường để ở trong một trạng thái cụ thể. Bạn không cần phải làm

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

Đó là vấn đề kéo vào (từ khóa toàn cầu) so với đẩy vào (đối số). Khi bạn đẩy vào / tiêm các phụ thuộc, hàm không dựa vào bên ngoài nữa. Khi bạn làm, fn(1)bạn không cần phải có một biến giữ 1 ở đâu đó bên ngoài. Nhưng khi bạn kéo vào toàn cục $onebên trong hàm, bạn sẽ ghép nối với phạm vi toàn cục và mong đợi nó có một biến của nó được xác định ở đâu đó. Khi đó hàm không còn độc lập nữa.

Thậm chí tệ hơn, khi bạn đang thay đổi các hình cầu bên trong hàm của mình, mã của bạn sẽ nhanh chóng hoàn toàn không thể hiểu được, bởi vì các hàm của bạn đang có tác dụng phụ ở khắp nơi.

Thiếu một ví dụ tốt hơn, hãy xem xét

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

Và sau đó bạn làm

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

Không có cách nào để thấy điều đó $foo đã thay đổi từ ba dòng này. Tại sao việc gọi cùng một hàm với các đối số giống nhau lại đột ngột thay đổi nó xuất ra hoặc thay đổi một giá trị trong trạng thái toàn cục? Một hàm nên thực hiện X cho một đầu vào Y. Luôn luôn.

Điều này thậm chí còn nghiêm trọng hơn khi sử dụng OOP, vì OOP là về tính đóng gói và bằng cách vươn ra phạm vi toàn cầu, bạn đang phá vỡ tính đóng gói. Tất cả các Singleton và Sổ đăng ký này mà bạn thấy trong các khuôn khổ đều là mã có mùi cần được loại bỏ để có lợi cho Dependency Injection. Tách mã của bạn.

Nhiêu tai nguyên hơn:

• http://c2.com/cgi/wiki?GlobalVariablesAreBad
• Làm thế nào để kiểm tra mô hình đăng ký hoặc singleton khó trong PHP?
• Flaw: Brittle Global State & Singletons
• static được coi là có hại
• Tại sao Singletons không được sử dụng trong PHP
• SOLID (thiết kế hướng đối tượng)

Một lý do lớn chống lại globallà nó có nghĩa là chức năng phụ thuộc vào phạm vi khác. Điều này sẽ trở nên lộn xộn rất nhanh chóng.

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

so với

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

Yêu cầu $str1và $str2được thiết lập trong phạm vi gọi để hàm hoạt động có nghĩa là bạn đưa vào các phụ thuộc không cần thiết. Bạn không thể đổi tên các biến này trong phạm vi này nữa mà không đổi tên chúng trong hàm và do đó cũng trong tất cả các phạm vi khác mà bạn đang sử dụng hàm này. Điều này sớm trở thành hỗn loạn khi bạn đang cố gắng theo dõi các tên biến của mình.

globallà một mô hình xấu ngay cả khi bao gồm những thứ toàn cầu như $dbtài nguyên. Có sẽ đến một ngày khi bạn muốn đổi tên $dbnhưng không thể, bởi vì toàn bộ ứng dụng của bạn phụ thuộc vào tên.

Giới hạn và phân tách phạm vi của các biến là điều cần thiết để viết bất kỳ ứng dụng phức tạp nào.

Quả cầu là không thể tránh khỏi.

Đó là một cuộc thảo luận cũ, nhưng tôi vẫn muốn thêm một số suy nghĩ vì tôi nhớ chúng trong các câu trả lời đã đề cập ở trên. Những câu trả lời đó đơn giản hóa những gì một toàn cầu là quá nhiều và đưa ra các giải pháp không phải là tất cả các giải pháp cho vấn đề. Vấn đề là: đâu là cách thích hợp để đối phó với một biến toàn cục và việc sử dụng từ khóa toàn cục? Để làm được điều đó, trước tiên chúng ta phải kiểm tra và mô tả toàn cầu là gì.

Hãy xem đoạn mã này của Zend - và hãy hiểu rằng tôi không cho rằng Zend bị viết xấu:

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',
   );

Có rất nhiều phụ thuộc vô hình ở đây. Các hằng số đó thực sự là các lớp. Bạn cũng có thể thấy request_once trong một số trang của khuôn khổ này. Request_once là một phụ thuộc toàn cục, do đó tạo ra các phụ thuộc bên ngoài. Đó là điều không thể tránh khỏi đối với một khuôn khổ. Làm thế nào bạn có thể tạo một lớp như DecoratorPluginManager mà không cần nhiều mã bên ngoài mà nó phụ thuộc vào? Nó không thể hoạt động nếu không có nhiều tính năng bổ sung. Sử dụng khung công tác Zend, bạn đã bao giờ thay đổi việc triển khai một giao diện chưa? Một giao diện trên thực tế là một toàn cầu.

Một ứng dụng khác được sử dụng trên toàn cầu là Drupal. Họ rất quan tâm đến thiết kế phù hợp, nhưng cũng giống như bất kỳ khuôn khổ lớn nào, chúng có rất nhiều yếu tố phụ thuộc bên ngoài. Hãy xem các hình cầu trong trang này:

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

Đã bao giờ viết một chuyển hướng đến trang đăng nhập? Điều đó đang thay đổi một giá trị toàn cầu. (Và sau đó bạn không nói 'WTF', mà tôi coi như một phản ứng tốt trước tài liệu xấu về ứng dụng của bạn.) Vấn đề với hình cầu không phải là chúng là hình cầu, bạn cần chúng để có một ứng dụng có ý nghĩa. Vấn đề là sự phức tạp của ứng dụng tổng thể có thể khiến nó trở thành cơn ác mộng để xử lý. Phiên là toàn cầu, $ _POST là toàn cầu, DRUPAL_ROOT là toàn cầu, bao gồm / install.core.inc 'là toàn cầu không thể thay đổi. Có một thế giới rộng lớn bên ngoài bất kỳ chức năng nào được yêu cầu để chức năng đó thực hiện công việc của nó.

Câu trả lời của Gordon là không chính xác, bởi vì anh ta đánh giá cao tính độc lập của một hàm và gọi một hàm là kẻ nói dối đang đơn giản hóa tình huống. Các hàm không nói dối và khi bạn xem ví dụ của anh ta, hàm được thiết kế không đúng - ví dụ của anh ta là một lỗi. (Nhân tiện, tôi đồng ý với kết luận này rằng người ta nên tách mã.) Câu trả lời của lừa dối không thực sự là một định nghĩa thích hợp về tình huống. Các hàm luôn hoạt động trong một phạm vi rộng hơn và ví dụ của anh ấy quá đơn giản. Tất cả chúng ta sẽ đồng ý với anh ta rằng hàm đó hoàn toàn vô dụng, bởi vì nó trả về một hằng số. Chức năng đó dù sao cũng là một thiết kế tồi. Nếu bạn muốn chỉ ra rằng thực hành là xấu, hãy đi kèm với một ví dụ có liên quan. Đổi tên các biến trong toàn bộ ứng dụng không phải là vấn đề lớn nếu có một IDE (hoặc một công cụ) tốt. Câu hỏi là về phạm vi của biến, không phải là sự khác biệt về phạm vi với hàm. Có một thời gian thích hợp để một hàm thực hiện vai trò của nó trong quy trình (đó là lý do tại sao nó được tạo ngay từ đầu) và vào thời điểm thích hợp đó nó có thể ảnh hưởng đến hoạt động của toàn bộ ứng dụng, do đó cũng hoạt động trên các biến toàn cục . Câu trả lời của xzyfer là một tuyên bố không cần tranh luận. Globals cũng xuất hiện trong ứng dụng nếu bạn có các hàm thủ tục hoặc thiết kế OOP. Hai cách tiếp theo để thay đổi giá trị của toàn cục về cơ bản giống nhau: do đó cũng làm việc trên các biến toàn cục. Câu trả lời của xzyfer là một tuyên bố không cần tranh luận. Globals cũng xuất hiện trong ứng dụng nếu bạn có các hàm thủ tục hoặc thiết kế OOP. Hai cách tiếp theo để thay đổi giá trị của toàn cục về cơ bản giống nhau: do đó cũng làm việc trên các biến toàn cục. Câu trả lời của xzyfer là một tuyên bố không cần tranh luận. Globals cũng xuất hiện trong ứng dụng nếu bạn có các hàm thủ tục hoặc thiết kế OOP. Hai cách tiếp theo để thay đổi giá trị của toàn cục về cơ bản giống nhau:

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

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

Trong cả hai trường hợp, giá trị của $ z được thay đổi trong một hàm cụ thể. Trong cả hai cách lập trình, bạn có thể thực hiện những thay đổi đó ở một loạt các vị trí khác trong mã. Bạn có thể nói rằng sử dụng global, bạn có thể gọi $ z ở bất kỳ đâu và thay đổi ở đó. Có, bạn có thể. Nhưng bạn sẽ? Và khi được thực hiện ở những nơi không phù hợp, nó sẽ không được gọi là lỗi?

Bob Fanger bình luận về xzyfer.

Sau đó có nên sử dụng bất cứ ai và đặc biệt là từ khóa 'toàn cầu' không? Không, nhưng cũng giống như bất kỳ kiểu thiết kế nào, hãy cố gắng phân tích xem nó phụ thuộc vào cái gì và cái gì phụ thuộc vào nó. Cố gắng tìm hiểu khi nào nó thay đổi và nó thay đổi như thế nào. Thay đổi giá trị toàn cục chỉ nên xảy ra với những biến có thể thay đổi theo mọi yêu cầu / phản hồi. Có nghĩa là, chỉ đối với những biến thuộc dòng chức năng của một quá trình, chứ không phải việc thực hiện kỹ thuật của nó. Việc chuyển hướng một URL đến trang đăng nhập thuộc về quy trình chức năng, lớp triển khai được sử dụng cho một giao diện để triển khai kỹ thuật. Bạn có thể thay đổi cái sau trong các phiên bản khác nhau của ứng dụng, nhưng không nên thay đổi cái sau với mọi yêu cầu / phản hồi.

Để hiểu rõ hơn khi nào đó là vấn đề khi làm việc với các hình cầu và từ khóa toàn cầu và khi nào thì không, tôi sẽ giới thiệu câu tiếp theo, xuất phát từ Wim de Bie khi viết về blog: 'Cá nhân có, riêng tư không'. Khi một hàm thay đổi giá trị của một biến toàn cục vì lợi ích của chính nó, thì tôi sẽ gọi đó là việc sử dụng riêng một biến toàn cục và một lỗi. Nhưng khi sự thay đổi của biến toàn cục được thực hiện để xử lý toàn bộ ứng dụng một cách thích hợp, chẳng hạn như chuyển hướng của người dùng đến trang đăng nhập, thì theo tôi đó có thể là thiết kế tốt, không phải là xấu và chắc chắn không phải là một chống hoa văn.

Hồi tưởng lại câu trả lời của Gordon, cheat và xzyfer: tất cả đều có 'có riêng' (và lỗi) làm ví dụ. Đó là lý do tại sao họ phản đối việc sử dụng các quả cầu. Tôi cũng sẽ làm. Tuy nhiên, chúng không đi kèm với các ví dụ 'cá nhân có, không riêng tư' như tôi đã làm trong câu trả lời này vài lần.

Nói một cách đơn giản, hiếm khi có lý do globalvà không bao giờ là lý do tốt trong mã PHP hiện đại IMHO. Đặc biệt nếu bạn đang sử dụng PHP 5. Và đặc biệt hơn nếu bạn đang phát triển mã Hướng đối tượng.

Toàn cầu ảnh hưởng tiêu cực đến khả năng bảo trì, khả năng đọc và khả năng kiểm tra của mã. Nhiều cách sử dụng globalcan và nên được thay thế bằng Dependency Injection hoặc đơn giản là truyền đối tượng toàn cục dưới dạng tham số.

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

Đừng ngần ngại sử dụng từ khóa toàn cục bên trong các hàm trong PHP. Đặc biệt đừng coi những người đang rao giảng / la hét một cách kỳ lạ rằng những quả cầu là 'xấu xa' và những thứ gì khác.

Thứ nhất, bởi vì những gì bạn sử dụng hoàn toàn phụ thuộc vào tình huống và vấn đề, và KHÔNG có một giải pháp / cách nào để làm bất cứ điều gì trong mã hóa. Hoàn toàn gạt bỏ sự ngụy biện của các tính từ không thể xác định, chủ quan, tôn giáo như 'ác' vào phương trình.

Trường hợp tại điểm :

Wordpress và hệ sinh thái của nó sử dụng từ khóa toàn cầu trong các chức năng của chúng. Là mã OOP hoặc không OOP.

Và cho đến nay, Wordpress về cơ bản là 18,9% Internet và nó đang chạy các megasites / ứng dụng khổng lồ của vô số người khổng lồ khác nhau, từ Reuters đến Sony, NYT, CNN.

Và nó hoạt động tốt.

Việc sử dụng từ khóa toàn cục bên trong các hàm giải phóng Wordpress khỏi sự phình to MASSIVE sẽ xảy ra với hệ sinh thái khổng lồ của nó. Hãy tưởng tượng mọi hàm đang hỏi / chuyển bất kỳ biến nào cần thiết từ một plugin, lõi và trả về khác. Được thêm vào với sự phụ thuộc lẫn nhau của plugin, điều đó sẽ dẫn đến một cơn ác mộng về các biến hoặc cơn ác mộng về các mảng được truyền dưới dạng biến. MỘT ĐỊA NGỤC để theo dõi, một địa ngục để gỡ lỗi, một địa ngục để phát triển. Dấu chân bộ nhớ không quá lớn do quá tải về mã và quá tải. Khó viết quá.

Có thể có những người đưa ra và chỉ trích Wordpress, hệ sinh thái của nó, hoạt động của họ và những gì diễn ra xung quanh những phần đó.

Vô nghĩa, vì hệ sinh thái này chiếm gần 20% toàn bộ mạng internet. Rõ ràng, nó KHÔNG hoạt động, nó làm công việc của mình và hơn thế nữa. Điều đó có nghĩa là nó giống nhau đối với từ khóa toàn cầu.

Một ví dụ điển hình khác là chủ nghĩa chính thống "iframe is evil". Một thập kỷ trước, việc sử dụng iframe là một dị giáo. Và có hàng ngàn người rao giảng chống lại họ trên internet. Sau đó đến facebook, rồi đến mạng xã hội, bây giờ iframe có ở khắp mọi nơi từ hộp 'thích' đến xác thực, và thì đấy - mọi người im lặng. Có những người vẫn không im lặng - dù đúng hay sai. Nhưng bạn biết không, cuộc sống vẫn tiếp diễn bất chấp những ý kiến ​​như vậy, và ngay cả những người đã rao giảng chống lại iframe cách đây một thập kỷ cũng đang phải sử dụng chúng để tích hợp các ứng dụng xã hội khác nhau vào các ứng dụng của tổ chức họ mà không cần nói một lời.

......

Chủ nghĩa cơ bản của Coder là một cái gì đó rất, rất tệ. Một tỷ lệ nhỏ trong chúng ta có thể hài lòng với công việc thoải mái trong một công ty nguyên khối vững chắc có đủ ảnh hưởng để chịu đựng sự thay đổi liên tục của công nghệ thông tin và những áp lực mà nó mang lại liên quan đến cạnh tranh, thời gian, ngân sách và các cân nhắc khác, và do đó có thể thực hành chủ nghĩa chính thống và tuân thủ nghiêm ngặt các 'tệ nạn' hoặc 'hàng hóa' được nhận thức. Đây là những vị trí thoải mái gợi nhớ về thời xưa, ngay cả khi những người ngồi trên xe là người trẻ tuổi.

Tuy nhiên, đối với đa số, thế giới này là một thế giới luôn thay đổi, trong đó họ cần có tư duy cởi mở và thực tế. Không có chỗ cho chủ nghĩa chính thống, hãy gạt bỏ những từ khóa phiến diện như 'ác quỷ' trong chiến hào công nghệ thông tin.

Chỉ cần sử dụng bất cứ điều gì phù hợp nhất cho vấn đề TẠI TAY, với những cân nhắc phù hợp cho tương lai gần, trung hạn và dài hạn. Đừng né tránh việc sử dụng bất kỳ tính năng hoặc cách tiếp cận nào bởi vì nó có tư tưởng thù địch tràn lan chống lại nó, trong số bất kỳ tập hợp con lập trình viên nhất định nào.

Họ sẽ không làm công việc của bạn. Bạn sẽ. Hành động theo hoàn cảnh của bạn.

Tôi nghĩ rằng mọi người đã giải thích khá nhiều về các khía cạnh tiêu cực của hình cầu. Vì vậy, tôi sẽ bổ sung những mặt tích cực cũng như hướng dẫn sử dụng đúng cách của quả cầu:

1. Mục đích chính của hình cầu là chia sẻ thông tin giữa các chức năng. trở lại khi không có gì giống như một lớp, mã php bao gồm một loạt các chức năng. Đôi khi bạn cần chia sẻ thông tin giữa các chức năng. Thông thường, toàn cầu đã được sử dụng để làm điều này với nguy cơ dữ liệu bị hỏng bằng cách biến chúng thành toàn cầu.

   Bây giờ trước khi một số người vui vẻ may mắn, simpleton bắt đầu nhận xét về việc tiêm phụ thuộc, tôi muốn hỏi bạn làm thế nào người dùng của một hàm như ví dụ get_post(1)sẽ biết tất cả các phụ thuộc của hàm. Cũng nên lưu ý rằng các phụ thuộc có thể khác nhau giữa các
   phiên bản và máy chủ này sang máy chủ khác. Vấn đề chính của việc tiêm phụ thuộc là các phụ thuộc phải được biết trước. Trong tình huống không thể thực hiện được hoặc các biến toàn cục không mong muốn là cách duy nhất để đạt được mục tiêu này.

   Do việc tạo lớp, giờ đây các hàm phổ biến có thể dễ dàng được nhóm lại trong một lớp và chia sẻ dữ liệu. Thông qua việc triển khai như Mediators, ngay cả những đối tượng không liên quan cũng có thể chia sẻ thông tin. Điều này không còn cần thiết nữa.

2. Một cách sử dụng khác cho hình cầu là cho mục đích cấu hình. Chủ yếu là ở phần đầu của tập lệnh trước khi bất kỳ trình tải tự động nào được tải, kết nối cơ sở dữ liệu được thực hiện, v.v.

   Trong quá trình tải tài nguyên, toàn cầu có thể được sử dụng để định cấu hình dữ liệu (tức là sử dụng cơ sở dữ liệu nào để đặt tệp thư viện, url của máy chủ, v.v.). Cách tốt nhất để làm điều này là sử dụng define()hàm vì các giá trị này sẽ không thay đổi thường xuyên và có thể dễ dàng được đặt trong tệp cấu hình.

3. Công dụng cuối cùng cho toàn cầu là lưu giữ dữ liệu chung (tức là CRLF, IMAGE_DIR, IMAGE_DIR_URL), cờ trạng thái có thể đọc được của con người (tức là ITERATOR_IS_RECURSIVE). Ở đây hình cầu được sử dụng để lưu trữ thông tin có nghĩa là được sử dụng trên toàn ứng dụng cho phép chúng được thay đổi và những thay đổi đó xuất hiện trên toàn ứng dụng.

4. Mô hình singleton trở nên phổ biến trong php trong thời gian php4 khi mỗi phiên bản của một đối tượng chiếm bộ nhớ. Singleton đã giúp tiết kiệm ram bằng cách chỉ cho phép một phiên bản của một đối tượng được tạo. Trước khi tham chiếu, thậm chí tiêm phụ thuộc sẽ là một ý tưởng tồi.

   Việc triển khai php mới của các đối tượng từ PHP 5.4+ sẽ giải quyết hầu hết các vấn đề này, bạn có thể chuyển các đối tượng xung quanh một cách an toàn mà không bị phạt gì thêm. Điều này không còn cần thiết nữa.

   Một cách sử dụng khác cho singleton là trường hợp đặc biệt mà chỉ một trường hợp của một đối tượng phải tồn tại tại một thời điểm, trường hợp đó có thể tồn tại trước / sau khi thực thi tập lệnh và đối tượng đó được chia sẻ giữa các tập lệnh / máy chủ / ngôn ngữ khác nhau, v.v. Ở đây một mẫu singleton giải quyết giải pháp khá tốt.

Vì vậy, kết luận nếu bạn đang ở vị trí 1, 2 hoặc 3 thì việc sử dụng toàn cục sẽ là hợp lý. Tuy nhiên, trong các tình huống khác nên sử dụng Phương pháp 1.

Vui lòng cập nhật bất kỳ trường hợp nào khác mà hình cầu nên được sử dụng.

Không có ý nghĩa gì khi tạo một hàm concat bằng cách sử dụng từ khóa chung.

Nó được sử dụng để truy cập các biến toàn cục như một đối tượng cơ sở dữ liệu.

Thí dụ:

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

Nó có thể được sử dụng như một biến thể trên mẫu Singleton