PHP глобальний у функціях


100

У чому полягає корисність глобального ключового слова ?

Чи є причини віддати перевагу одному методу іншому?

  • Безпека?
  • Продуктивність?
  • Щось іще?

Спосіб 1:

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

Спосіб 2:

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

Коли є сенс використовувати global?

Для мене це видається небезпечним ... але це може бути просто відсутність знань. Мене цікавлять документально підтверджені (наприклад, з прикладом коду, посилання на документацію ...) технічні причини.

Спасибі заздалегідь!


Баунті

Це хороше загальне запитання щодо цієї теми, я (@Gordon) пропоную щедро, щоб отримати додаткові відповіді. Чи відповідає ваша відповідь з моєю чи надає іншу точку зору, не має значення. Оскільки ця globalтема виникає раз у раз, ми можемо використати добру "канонічну" відповідь для посилання.


2
подивіться на це посилання: stackoverflow.com/questions/1557787 У правій нижній частині цієї сторінки дуже багато пов’язаних статей
JohnP

Це не пряма відповідь на ваше запитання, але, будь ласка, прочитайте це старе питання .
flafur Waage

1
Отже, я не можу прочитати жодне проглобальне ключове слово. 1) Чому саме тут. 2) Чому люди його використовують?
Паскаль Qyy

@ G.Qyy Чому існує goto? Чому люди його використовують? Вони не користуються цим (принаймні сподіваюся): P
PeeHaa

Наприкінці минулого року (14 грудня) хтось спротив це питання. Мені дуже цікаво знати, чому всі точки зору, включаючи негативні, цікаві. У цьому випадку як ніколи! Я буду дуже вдячний за будь-яку підказку про це.
Паскаль Qyy

Відповіді:


158

Глобали - це зло

Це справедливо як для globalключового слова, так і для всього іншого, що сягає від локальної сфери до глобальної сфери (статики, синглтонів, реєстрів, констант). Ви не хочете ними користуватися. Виклик функції не повинен покладатися ні на що зовні, наприклад,

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
}

Все це зробить ваш код залежним від зовнішньої сторони. Це означає, що ви повинні знати повний глобальний стан, у якому знаходиться ваша заявка, перш ніж ви зможете надійно викликати будь-яке з них. Функція не може існувати без цього середовища.

Використання суперглобалів може бути не очевидним недоліком, але якщо ви називаєте свій код із командного рядка, у вас немає $_GETабо$_POST . Якщо ваш код покладається на вхід з цих даних, ви обмежуєте себе веб-середовищем. Просто абстрагуйте запит на об’єкт і використовуйте його замість цього.

У разі з’єднання жорстко кодованих імен класів (статичних, константних) ваша функція також не може існувати без наявності цього класу. Це менше питання, коли це класи з одного простору імен, але коли ви починаєте змішувати з різних просторів імен, ви створюєте заплутаний безлад.

Повторне використання сильно перешкоджає усьому вищесказаному. Так само і тестування одиниць .

Крім того, підписи вашої функції лежать, коли ви підключаєтесь до глобальної сфери

function fn()

є брехуном, тому що він стверджує, що я можу викликати цю функцію, нічого не передаючи їй. Лише коли я дивлюся на функціональний орган, я дізнаюся, що я повинен перевести навколишнє середовище у певний стан.

Якщо ваша функція вимагає запуску аргументів, зробіть їх явними і передайте їх у:

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

чітко передає з підпису те, що потрібно викликати. Не залежно від того, щоб навколишнє середовище знаходилось у конкретному стані. Ви не повинні робити

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

Це питання втягування (глобальне ключове слово) проти втілення (аргументи). Коли ви натискаєте на / вводить залежності, функція більше не покладається на зовнішню сторону. Коли ви робитеfn(1) не повинні мати змінну, що займає 1 десь на вулиці. Але коли ви втягуєте $oneвсередину функції всередині, ви підключаєтесь до глобальної сфери і очікуєте, що вона має змінну тієї, що десь визначена. Функція тоді вже не є незалежною.

Ще гірше, коли ви змінюєте глобальні знаки всередині своєї функції, ваш код буде швидко незрозумілим, оскільки ваші функції мають побічні ефекти з усього місця.

Відсутність кращого прикладу, врахуйте

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

І тоді ви робите

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

Немає способу це побачити $foo змінилося з цих трьох рядків. Чому б викликати ту саму функцію однаковими аргументами, раптово змінити її вихід або змінити значення в глобальному стані? Функція повинна робити X для визначеного входу Y. Завжди.

Це стає ще більш серйозним при використанні OOP, оскільки OOP стосується інкапсуляції і, досягнувши глобальної мети, ви порушуєте інкапсуляцію. Усі ці одиночні та реєстри, які ви бачите в рамках, є запахами коду, які слід видалити на користь ін'єкції залежності. Розв’яжіть свій код.

Більше ресурсів:


10
Чому PHP реалізує такі речі? Чи є утиліта? Я завжди дивуюсь небезпечним реалізаціям PHP, якими багато людей користуються щоразу ... Мені важко повірити, що немає логічних причин!
Паскаль Qyy

5
Я б хотів, щоб ти міг зробити глобальних людей зла більше.
Керміт

3
Нічого собі, нарешті хтось добре пояснив, чому глобальні люди є злими ... Я завжди чув, що вони є, і я бачив кілька дуже конкретних прикладів, чому це, але це справді хороше і всебічне пояснення з загальної причини, чому. +1
Wingblade

Я справді запізнююся, і я начебто розумію, що ви говорите, але як щодо з'єднань mysqli? Якщо вони щоразу передаються як параметр, або це глобальне $ посилання; дозволений у ваших очах?
Mave

2
Ви маєте рацію, крім констант. Вони не являють собою "стан" програми, і нормально посилатися на них зсередини функції. Функція не «лежить», якщо вона використовує константу зсередини. Я погоджуюся, що це означає, що програміст в один момент знав зовнішню сторону, але це дуже прийнятна компроміс для того, що є постійною. Крім того, якщо серйозно, це не надто велика угода.
Себас

35

Одна з головних причин globalполягає в тому, що це означає, що функція залежить від іншої області. Це швидко забрудниться.

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

vs.

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

Вимога $str1та $str2налаштування в області виклику для функціонування означає, що ви вводите непотрібні залежності. Ви більше не можете перейменовувати ці змінні в цій області, не перейменуючи їх у функцію, а отже, і у всіх інших областях, якими ви користуєтесь цією функцією. Це незабаром перетворюється на хаос, коли ви намагаєтесь відслідковувати свої імена змінних.

globalє поганою схемою навіть для включення таких глобальних речей, як $dbресурси. Там буде настане день , коли ви хочете перейменувати , $dbале не може, тому що все ваше додаток залежить від імені.

Обмеження та розділення сфери змінних має важливе значення для написання будь-якого наполовину складного додатку.


1
Вибачте, але чому я напевно хотів би перейменувати $db? Це PDO, що проходить скрізь. Чому це було б змінено, коли я можу оновити інформацію про з'єднання окремо?
Кейсі Дуейн

3
@kcd Оскільки одного дня ви усвідомлюєте, наскільки велика ін'єкція залежності, і хочете реструктурувати додаток? Тому що одного дня вам потрібно буде інтегрувати свої речі з деякими іншими речами, які також використовують глобальну $dbзмінну? Тому що одного дня ви відкриєте для тестування одиниці і для цього потрібно керувати кількома підключеннями до бази даних одночасно? Багато, багато причин.
деле

35

Глобали неминучі.

Це давнє обговорення, але я все ж хотів би додати деякі думки, тому що я пропускаю їх у вищезгаданих відповідях. Ці відповіді спрощують те, що глобальний - це занадто багато, і представляють рішення, які зовсім не є вирішенням проблеми. Проблема полягає в тому, що є правильним способом боротьби із глобальною змінною та використанням ключового слова global? Для цього ми спочатку повинні вивчити та описати, що таке глобальний.

Погляньте на цей код Zend - і, будь ласка, зрозумійте, що я не припускаю, що Zend погано написаний:

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

Тут дуже багато невидимих ​​залежностей. Ці константи - це фактично класи. Ви також можете побачити Requ_once на деяких сторінках цього фреймворку. Require_once - це глобальна залежність, отже, створюється зовнішня залежність. Це неминуче для рамки. Як можна створити такий клас, як DecoratorPluginManager, без багато зовнішнього коду, від якого це залежить? Він не може функціонувати без безлічі додатків. Використовуючи рамку Zend, ви коли-небудь змінювали реалізацію інтерфейсу? Насправді інтерфейс є глобальним.

Ще одне глобально використовуване додаток - Drupal. Вони дуже стурбовані правильним дизайном, але, як і будь-які великі рамки, у них багато зовнішніх залежностей. Погляньте на глобалістів на цій сторінці:

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

Ви коли-небудь писали переспрямування на сторінку входу? Це змінює глобальне значення. (Тоді ви не говорите "WTF", що я вважаю хорошою реакцією на погану документацію вашої заявки.) Проблема глобальних мереж полягає не в тому, що вони глобальні, вони вам потрібні для того, щоб мати змістовне застосування. Проблема полягає у складності загальної програми, яка може зробити її кошмаром. Сесії - глобальні, $ _POST - глобальний, DRUPAL_ROOT - глобальний, включаючи / install.core.inc '- глобальний, що не може змінюватися. Поза межами будь-якої функції є великий світ, який необхідний для того, щоб дозволити цій функції виконувати свою роботу.

Відповідь Гордона невірна, оскільки він завищує незалежність функції і називає функцію брехуном - це надто спрощує ситуацію. Функції не брешуть, і коли ви дивитесь на його приклад, функція розроблена неправильно - його приклад - помилка. (До речі, я погоджуюся з таким висновком, що слід роз'єднати код.) Відповідь обману насправді не є правильним визначенням ситуації. Функції завжди функціонують у більш широкому обсязі, і його приклад є занадто спрощеним. Всі ми погодимося з ним, що ця функція є абсолютно марною, оскільки вона повертає константу. Ця функція все одно погана конструкція. Якщо ви хочете показати, що практика погана, будь ласка, будьте відповідним прикладом. Перейменування змінних у всій програмі не є великою справою, маючи хороший IDE (або інструмент). Питання стосується сфери дії змінної, а не різниці в області застосування з функцією. Існує належний час, коли функція може виконувати свою роль у процесі (саме тому вона створюється в першу чергу), і в цей належний час може вплинути на функціонування програми в цілому, отже, також працює над глобальними змінними . Відповідь xzyfer - це твердження без аргументації. Глобали так само є в програмі, якщо у вас є процедурні функції або дизайн OOP. Наступні два способи зміни значення глобальної суті однакові: отже, також працює над глобальними змінними. Відповідь xzyfer - це твердження без аргументації. Глобали так само є в програмі, якщо у вас є процедурні функції або дизайн OOP. Наступні два способи зміни значення глобальної суті однакові: отже, також працює над глобальними змінними. Відповідь xzyfer - це твердження без аргументації. Глобали так само є в програмі, якщо у вас є процедурні функції або дизайн OOP. Наступні два способи зміни значення глобальної суті однакові:

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

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

В обох випадках значення $ z змінюється в межах конкретної функції. В обох способах програмування ви можете внести ці зміни в купу інших місць коду. Можна сказати, що, використовуючи глобальний, ви можете зателефонувати в $ z і змінити там. Так, ти можеш. Але ти будеш? І коли це робиться в невідповідних місцях, чи не слід це називати клопом?

Bob Fanger коментує xzyfer.

Чи повинен тоді хтось просто використовувати щось, особливо ключове слово «глобальний»? Ні, але, як і будь-який тип дизайну, спробуйте проаналізувати, від чого це залежить і від чого залежить. Спробуйте дізнатися, коли вона змінюється і як вона змінюється. Зміна глобальних значень має відбуватися лише з тими змінними, які можуть змінюватися з кожним запитом / відповіддю. Тобто лише до тих змінних, які належать до функціонального потоку процесу, а не до його технічної реалізації. Перенаправлення URL-адреси на сторінку входу належить до функціонального потоку процесу, класу реалізації, який використовується для інтерфейсу технічної реалізації. Ви можете змінити останню під час різних версій програми, але не слід змінювати їх із кожним запитом / відповіддю.

Для подальшого розуміння, коли це проблема з глобалізацією та ключовим словом глобальний, а коли ні, я введу наступне речення, яке походить від Віма де Бі, коли він пише про блоги: "Особистий так, приватний ні". Коли функція змінює значення глобальної змінної заради власного функціонування, то я буду називати приватне використання глобальної змінної та помилку. Але коли зміна глобальної змінної робиться для належної обробки додатку в цілому, як перенаправлення користувача на сторінку входу, то, на мою думку, це можливо хороший дизайн, а не за визначенням поганий і, звичайно, не анти-візерунок.

Зрештою, на відповіді Гордона, deze та xzyfer: всі вони мають "приватний" (та помилки) як приклади. Ось чому вони проти використання глобалів. Я б теж зробив. Однак вони не мають «особистого так, приватних ні-прикладів», як я робив у цій відповіді кілька разів.


Зразок коду Друпала не використовує глобали, він використовує константи. Дуже важлива відмінність полягає в тому, що константа не може бути переглянута після її визначення. Також ви не можете просто порівняти функції xyzта setZ. Перший змінює глобальний стан, другий - метод класу і лише змінює стан екземпляра, до якого він викликався.
Ар’ян

@Arjen: якщо шукати ключове слово global у Drupal 7.14, то отримаєш сотні звернень. Це стара проблема з громадськими секторами: ви не контролюєте те місце, де вони змінюються, коли ви оприлюднили їх. Рекомендовано взагалі не використовувати їх або оголошувати їх приватними, тому це не можна буде додавати пізніше.
Лоек Бергман

@Arjan: через мою помилку із написанням вашого імені ви не отримали жодного повідомлення про мою відповідь до вас. Тепер ти будеш. :-)
Лоек Бергман

@LoekBergman: Існує близько 400 звернень до слова globalв друпал 7,26 (що є останньою версією), деякі з цих звернень є у коментарях, а кілька інших, схоже, в коді, який не торкався роками. Я впевнений, що вони не використовуватимуть globals drupal 8.
Ар'ян

@LoekBergman Будь ласка, використовуйте сетерів та геттерів. Це не займає багато часу, щоб налаштувати і дозволяє іншим, хто використовує ваш код, і, можливо, розширює ваші класи, мати більше контролю. Як тільки ви зробите параметр загальнодоступним, це його. у вас немає можливості приховати це згодом.
mAsT3RpEE

15

Простіше кажучи, globalв сучасному PHP-коді IMHO рідко є причина і ніколи не є хорошим. Особливо, якщо ви використовуєте PHP 5. І особливо спеціально, якщо ви розробляєте об'єктно-орієнтований код.

Глобали негативно впливають на ремонтопридатність, читабельність та заповітність коду. Багато застосувань globalможуть і повинні бути замінені на введення залежностей або просто передачу глобального об'єкта як параметр.

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

10

Не соромтесь використовувати глобальне ключове слово всередині функцій у PHP. Особливо не приймайте людей, котрі чудово проповідують / кричать про те, як глобальні люди є «злими» і що ні.

По-перше, адже те, що ви повністю використовуєте, залежить від ситуації та проблеми, і немає жодного рішення / способу зробити що-небудь у кодуванні. Повністю залишаючи осторонь помилковість невизначених, суб'єктивних, релігійних прикметників типу "зла" в рівнянні.

Справа в точці:

Wordpress та його екосистема використовує глобальне ключове слово у своїх функціях. Будьте кодом OOP чи ні OOP.

На сьогодні Wordpress - це 18,9% Інтернету, і він працює з величезними мегаситами / додатками незліченних гігантів, починаючи від Reuters до Sony, NYT, CNN.

І це робить добре.

Використання глобального ключового слова всередині функцій звільняє Wordpress від МАСИВНОГО набряку, що може статися з огляду на його величезну екосистему. Уявіть, що кожна функція запитувала / передавала будь-яку змінну, необхідну з іншого плагіна, ядра та повернення. Додано взаємозалежності плагінів, що може закінчитися кошмаром змінних або кошмаром масивів, що передаються як змінні. ПЕКЛО відслідковувати, пекло налагоджувати, пекло розвиватися. Ненадійний масивний слід пам'яті через роздуття коду та змінний показ. Складніше писати теж.

Можуть бути люди, які придумують і критикують Wordpress, його екосистему, їхню практику та те, що відбувається в цих частинах.

Безглуздо, оскільки ця екосистема становить майже 20% приблизно усього Інтернет. Судячи з усього, воно ТОЛЬКО працює, робить свою роботу та інше. Що означає його те саме для глобального ключового слова.

Ще один хороший приклад - фундаменталізм "рамки зла". Десять років тому було єресі використовувати рамки. А тисячі людей проповідували проти них Інтернет. Потім приходить фейсбук, потім приходить соцмережа, тепер іфрейми є скрізь - від "як" скриньки до аутентифікації, і вуаля - всі заткнуться. Є ті, хто досі не заткнувся - справедливо чи неправильно. Але ви знаєте що, життя продовжується, незважаючи на таку думку, і навіть ті, хто десять років тому проповідував проти iframes, тепер їм доводиться використовувати їх для інтеграції різних соціальних програм у власні програми своєї організації, не кажучи ні слова.

......

Фундаменталізм кодерів - це щось дуже, дуже погане. Невеликий відсоток серед нас може бути пов'язаний з комфортною роботою в солідній монолітній компанії, яка має достатньо зусиль, щоб витримати постійні зміни інформаційних технологій та тиску, яке вона викликає у зв'язку з конкуренцією, часом, бюджетом та іншими міркуваннями, а тому може практикувати фундаменталізм і чітке дотримання сприйнятого "зла" або "блага". Зручні посади, що нагадують старі віки, є навіть, якщо окупанти молоді.

Однак для більшості, це світ є постійно мінливим світом, в якому вони повинні бути відкритими і практичними. Тут немає місця фундаменталізму, залиште осторонь кричущі ключові слова, такі як "зло", в траншеях інформаційних технологій.

Просто використовуйте все, що має найкращий сенс для проблеми НА РУКАХ, з відповідними міркуваннями щодо найближчого, середньо- та довгострокового майбутнього. Не ухиляйтесь від використання будь-якої функції або підходу, оскільки він має бурхливу ідеологічну ворожнечу серед будь-якого даного набору кодерів.

Вони не будуть робити вашу роботу. Ти будеш. Дійте відповідно до ваших обставин.


3
+1 для антифундаменталізму тощо, але сказати, що "багато людей використовують це / воно працює / тощо" - це лише "аргумент ad populum", базовий софізм. факт, що більшість людей думає або робить одне, не доводить, що вони праві! у натовпі, якщо з’явиться небезпека, більшість людей робитимуть дурні речі, а деякі люди помруть, затоплені іншими. Чи правильно вони покласти ногу на обличчя цієї п’ятирічної дівчинки лише тому, що вони думають, що вони повинні абсолютно штовхнути двері, які відкриються, лише якщо її потягнуть, щоб уникнути пожежі? Я не думаю, що так ...
Паскаль Qyy

1
більшість, що робить щось звичайно, нічого не підтверджує. проте справа - це програмне забезпечення. і якщо більшість це робить, і більшість створених цими людьми додатків і служб добре (Wordpress для багатьох інших), то це означає, що ними можна користуватися.
єдність100

7

Я думаю, що кожен майже пояснив негативні аспекти глобальної сфери. Тож я додам позитиви, а також інструкції щодо правильного використання глобалів:

  1. Основна мета глобалів полягала в обміні інформацією між функціями. Ще коли не було нічого подібного до класу, php-код складався з купки функцій. Іноді вам потрібно буде обмінюватися інформацією між функціями. Як правило, для цього використовували глобальний ризик пошкодити дані, зробивши їх глобальними.

    Тепер, перш ніж якийсь щасливий простий попросту розпочне коментар про введення залежності, я хотів би запитати вас, як користувач функції, наприклад get_post(1), знав усі залежності функції. Також врахуйте, що залежності можуть відрізнятися від
    версії до версії та від сервера до сервера. Основна проблема введення наркоманії - це залежності, які мають бути відомі заздалегідь. У ситуації, коли це неможливо або небажані глобальні змінні були єдиним способом досягти цієї мети.

    Завдяки створенню класу, тепер загальні функції можна легко згрупувати в клас та обмінюватися даними. Завдяки таким реалізаціям, як Медіатори, навіть споріднені об'єкти можуть обмінюватися інформацією. Це більше не потрібно.

  2. Інше використання для глобальних мереж - для конфігурації. Переважно на початку сценарію до завантаження будь-яких автозавантажувачів, підключення до бази даних тощо.

    Під час завантаження ресурсів глобали можна використовувати для налаштування даних (тобто, яку базу даних використовувати, де знаходяться файли бібліотеки, URL-адресу сервера тощо). Найкращий спосіб зробити це за допомогою define()функції, оскільки ці значення часто змінюються і їх можна легко помістити у файл конфігурації.

  3. Остаточне використання для глобальних мереж - зберігання загальних даних (наприклад, CRLF, IMAGE_DIR, IMAGE_DIR_URL), прапорів, що читаються людиною (тобто ITERATOR_IS_RECURSIVE). Тут глобальні символи використовуються для зберігання інформації, яка призначена для використання додатків у широких межах, що дозволяє їх змінювати, і ці зміни з’являються додатками широко.

  4. Однотонний візерунок став популярним у php під час php4, коли кожен екземпляр об'єкта займав пам'ять. Синглтон допоміг зберегти оперативної пам'яті, дозволивши створити лише один екземпляр об'єкта. Перед тим, як згадати навіть ін'єкційну залежність, було б поганою ідеєю.

    Нова реалізація об'єктів PHP з PHP 5.4+ піклується про більшість цих проблем, ви можете безпечно передавати об'єкти навколо майже без жодного штрафу. Це більше не потрібно.

    Інше використання для одиночних клавіш - це спеціальний екземпляр, коли одночасно повинен існувати лише один екземпляр об'єкта, цей екземпляр може існувати до / після виконання сценарію, і цей об’єкт розділяється між різними сценаріями / серверами / мовами і т.д. рішення досить добре.

Отже, на закінчення, якщо ви перебуваєте в позиції 1, 2 або 3, то використання глобального було б розумним. Однак в інших ситуаціях слід використовувати метод 1.

Не соромтеся оновлювати будь-які інші випадки, де слід використовувати глобальні кулі.


6

Немає сенсу робити лаконічну функцію, використовуючи глобальне ключове слово.

Він використовується для доступу до глобальних змінних, таких як об'єкт бази даних.

Приклад:

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

Він може бути використаний як варіант на малюнку Singleton


"це не має сенсу" - насправді це так: прикладом буде реалізація таблиці пошуку без використання OOP.
Нір Альфасі
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.