Як треба і як не треба використовувати масиви в php у прикладах · GitHub

Як треба і як не треба використовувати масиви у php у прикладах

Давайте почнемо з питання, а що таке масиви в php, і навіщо вони потрібні

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

Ось який великий список можливостей, а давайте подивимося, що з цього приводу говорить Вікіпедія

Масив - набір однотипних компонентів (елементів), розташованих у пам'яті безпосередньо один за одним, доступ до яких здійснюється за індексом (індексами).

Ось це вже цікаво, виходить у нас в PHP представлено 2 абсолютно різних типи масивів, перше це звичайний масив з однотипними елементами, і друге цей той масив що використовується в php, його я називатиму асоціативні

А тепер давайте приступимо до того, чому масиви це добре, а асоціативні масиви не дуже добре здебільшого.

Легкість, лише індекси, лише хардкор
Ми завжди знаємо, що там за об'єкт (за фактом у пхп це не так, це могло б бути так, але занадто багато проголосувала проти arrayof на rfc https://wiki.php.net/rfc/arrayof)

Плюси асоціативних масивів

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

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

Виняток це функції для обробки значень, що прийшли з поза, $_GET, $_POST і т.д.

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

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

Основні проблеми

Постійна відсутність ключів

Важко шукати помилки

Приклад із життя

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

Якби ми використовували класи, ми дізналися про помилки ще на етапі встановлення параметрів даного класу.

Як можна замінити асоціативні масиви

Розглянемо приклад із фреймверку codeigniter

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

Як можна замінити?

Які плюси ми отримаємо від такого підходу, підказки IDE, ми можемо дізнатися про всі можливості класу навіть не відкриваючи документацію, валідацією та обробкою даних займається PaginationConfig, виключені помилки в ключах, ось такий список плюсів,ми можемо отримати такі невеликі зміни.