Как да и как да не използваме масиви в php в примери GitHub
Как да и как да не използваме масиви в php в примери
Нека започнем с въпроса какво представляват масивите в php и защо са необходими?
Масивът в PHP е подредено картографиране, което картографира стойност към ключ. Този тип е оптимизиран по няколко начина, така че можете да го използвате като самия масив, списък (вектор), хеш таблица (която е реализация на карта), речник, колекция, стек, опашка и евентуално нещо друго. Тъй като стойността на един масив може да бъде друг PHP масив, можете също да създавате дървета и многоизмерни масиви.
Ето голям списък с функции, нека видим какво има да каже Wikipedia за него
Масивът е набор от подобни компоненти (елементи), разположени в паметта директно един след друг, достъпни чрез индекс (индекси).
Това вече е интересно, оказва се, че имаме 2 напълно различни вида масиви в PHP, първият е обикновен масив с един и същи тип елементи, а вторият е масивът, който се използва в php, ще го нарека асоциативен
Сега нека да разберем защо масивите са добри, а асоциативните масиви не са толкова добри в повечето случаи.
- Лек, само индекси, само хардкор
- Винаги знаем какъв вид обект има (всъщност в PHP това не е така, може да е така, но гласувахме твърде много против arrayof на rfc https://wiki.php.net/rfc/arrayof)
Предимства на асоциативните масиви
Ако всичко е ясно с масиви, а след това не с асоциативни, сега ще се опитам да напиша кога и как могат да се използват и този код може да доведе до не много успешни резултати.
- Асоциативен масив като параметърфункция или клас В повечето случаи това е лошо, тъй като не можем да знаем кои ключове трябва и кои не трябва да бъдат в него, кои от тях са необходими и кои не. В резултат на това всичко се превръща в игра на отгатване и постоянно ровене в документация.
Изключение са функции за обработка на стойности, дошли отвън, $_GET, $_POST и т.н.
Връщане на резултата като асоциативен масив Не знаем какво точно ще получим, нямаме подсказки в IDE и имаме нужда от постоянни проверки за наличие на ключ в масива.
Конфигурационни асоциативни масиви Да, чухте правилно, не харесвам конфигурационните масиви, те имат всички същите недостатъци и правят класовете, които ще ги приемат като вход, по-сложни.
Основни проблеми
Постоянна липса на ключове
Трудно намиране на грешки
Пример от живота
Някъде дълбоко в кода на рамката се появява грешка, че ключът не съществува в масива и ние започваме да проучваме, в резултат на това след няколко часа стигаме до факта, че просто сме забравили да посочим празен масив като последен параметър в масива в конфигурационния масив.
Ако бяхме използвали класове, щяхме да знаем за грешката на етапа на настройка на параметрите на този клас.
Как да заменим асоциативните масиви
Помислете за пример от рамката codeigniter
Минуси на лицето, невъзможно е да се открият всички възможни атрибути, валидирането на данните ще трябва да се извърши в класа на пагинатора, възможни са грешки в ключовете.
Как мога да заменя.
Какви са предимствата, които получаваме от този подход, IDE съвети, можем да разберем всички характеристики на класа, без дори да отваряме документацията, PaginationConfig се занимава с валидиране и обработка на данни, грешки в ключовете са изключени, ето такъв списък с предимства,можем да получим, като направим такива малки промени.