Давайте начнем с вопроса, а что же такое массивы в php, и зачем они нужны
Массив в PHP - это упорядоченное отображение, которое устанавливает соответствие между значением и ключом. Этот тип оптимизирован в нескольких направлениях, поэтому вы можете использовать его как собственно массив, список (вектор), хэш-таблицу (являющуюся реализацией карты), словарь, коллекцию, стэк, очередь и, возможно, что-то еще. Так как значением массива может быть другой массив PHP, можно также создавать деревья и многомерные массивы.
Источник: http://www.php.net/manual/ru/language.types.array.php
Вот какой большой список возможностей, а давайте посмотрим что по этом поводу говорит Википедия
Массив — набор однотипных компонентов (элементов), расположенных в памяти непосредственно друг за другом, доступ к которым осуществляется по индексу (индексам).
В ряде языков программирования, например, Лисп, JavaScript, PHP, Ruby применяются также ассоциативные массивы (или хэш-массивы), в которых элементы не обязательно являются однотипными, а доступ к ним не обязательно осуществляется по индексу.
Вот это уже интересно, получается у нас в PHP представлено 2 совершенно разных типа массивов, первое это обычный массив с однотипными элементами, и второе этот тот массив что используется в php, его я буду называть ассоциативные
А теперь давайте приступим к тому, почему массивы это хорошо, а ассоциативные массивы не очень хорошо в большинстве случаев.
Плюсы массивов
- Легкость, только индексы, только хардкор
- Мы всегда знаем что там за объект ( по факту в пхп это не так, это могло бы быть так, но слишком много проголосовала против arrayof на rfc https://wiki.php.net/rfc/arrayof)
Плюсы ассоциативных массивов
- Кажущаяся легкость
Если с массивами все понятно, то вот с ассоциативными нет, сейчас я попробую написать, когда и как их можно использовать, а кода это может привести к не очень удачным результатам.
- Ассоциативный массив как параметр функции или класса В большинстве случаев это плохо, так как мы не можем знать какие в нем должны быть ключи, а какие нет, какие из них обязательные, а какие нет. В результате все это превращается в угадайку и постоянное лазание в документацию.
Исключение это функции для обработки значений пришедших из вне, $_GET, $_POST и т.д.
-
Возврат результата в виде ассоциативного массива Мы не знаем что именно получим, у нас нет подсказок в IDE, и нам нужны постоянные проверки на присутствия ключа в массиве.
-
Конфигурационные ассоциативный массивы Да, вам не послышалось, мне не нравятся конфигурационные массивы, они обладают все теме же недостатками, и заствляют усложнять классы которые будут принимать их на вход.
Основные проблемы
-
Постоянное отсутствие ключей
-
Сложно искать ошибки
Пример из жизни
Где то глубоко в коде фреймверка выскакивает ошибка, о том что ключ в массиве не существует, и мы начинаем исследование, в результате через несколько часов мы приходим к тому что мы в конфигурационном массиве просто забыли указать последним параметром в массиве пустой массив.
Если бы мы использовали классы, мы бы узнали об ошибки еще на этапе установки параметров данного класса.
Как можно заменить ассоциативные массивы
Рассмотрим пример из фреймверка codeigniter
Изначальный код
$config['base_url'] = 'http://example.com/index.php/test/page/';
$config['total_rows'] = 200;
$config['per_page'] = 20;
$this->pagination->initialize($config); Минусы на лицо, нельзя узнать все возможные атрибуты, валидацию данных придется делать в классе паджинатора, возможны ошибки в ключах.
Как можно заменить.
$config = new PaginationConfig();
$config->setBaseUrl('http://example.com/index.php/test/page/');
$config->totalRows(200);
$config->perPage(20);
$this->pagination->initialize($config); Какие плюсы мы получим от такого подхода, подсказки IDE, мы можем узнать все возможности класса даже не открывая документацию, валидацией и обработкой данных занимается PaginationConfig, исключены ошибки в ключах, вот такой список плюсов, мы можем получить произведя такие небольшие изменения.