Пишу сейчас код для REST API. В одном из примеров реализации увидtл такую штуку... Code: $retJson=json_decode("{}"); $retJson->msg='lol'; exit(json_encode($retJson)); - вопрос закономерный... ЧТО лучше ассоциативные массивы или объекты??? Я привык к массивам можно там сделать что-то типа is_array array_key_exist... а с объектами так разве сделаешь?... В общем в замешательстве... может я осталый )
Объекты обычно делаются там, где все значения строго определены и не меняются, например в конфигах и т.п., а если хранятся данные, в ассоциативном массиве например, то они так и остаются. Пример для 1-го: PHP: $obj = (object)array('mysql' => json_decode($mysql)); var_dump($obj->mysql->pass); Пример для 2-го: PHP: $obj = (object)array('UserAgent' => json_decode($UA)); var_dump($obj->UserAgent['firefox'][mt_rand(0, (count($obj->UserAgent['firefox'])-1))]); PHP: $obj = json_decode("{}");//Так делать как-то криво
Только массивы, только хардкор. Какой смысл создавать объекты, если хватает массивов? Т.е. неужели вам нужны все прелести ООП, полиморфизм, инкапсуляцию для хранения конфигов? Вы уверены? Т.е. смысл выделять кучу памяти под объекты, если вы хотите всего лишь хранить сроковые данные? )))) Я, конечно, параноик. Но это правда избыточно )
Знакомый гуру, говорит что порой array_key_exists работает быстрей чем isset. Ну и конечно же call_user_func_array быстрей чем $obj->$method (это если вы собрались делать какие либо фабрики...) Лично я еще с 3 PHP пользовался массивами... привык. Было бы не плохо посмотреть исходники PHP на предмет функций isset, empty. array_key_exist. Надеюсь что ассоциативные массивы это годные хеш таблицы... 2 XAMEHA, не мог бы написать, что там выводит var_dump ?
Вы все верно господа подметили, хорошо, что есть такие товарищи как вы. Начинающие хотябы на этом этапе не запутаются в выборе ориентации программирования.
думаю что решает технология и проект. drupal юзает массив и процедурное . zend или symfony строго ооп. смотря что ты делашь . зависит от проекта и архитектуры. есть патеры которые оборачивают процедурное в ооп программирование. ты же не скажешь что я буду переписывать весь проект потому что ооп не знаю. или не люблю. так же не скажешь что не буду работать с массивами. говорить что массивы решают имхо бред. есть куча вещей которые в ооп просто решают. магические методы и всякие там патерны проектирования и всякие пре диспатчеры у фрейворков, тот же ORM.к тому же повышается читаемость кода. не думаю что кому то проще читать портянку кода в 1000 строк . а вопросы производительности. лично я считаю что лучше купить еще 1 серв за 2000$ чем потратить 200 000$ но оптимизацию кода который станет работать на 2о% быстрей. но это не я сам придумал. мне это объяснил 10ток людей имеющих опыт в высоконагрузочном программировании . а тебе раз ты начинаешь не надо думать еще о таких вопросах. лет через 5 если не забросишь будешь возвращаться. пока учи все и массивы и ооп. А вообще как пишет Макконел в "Совершенный код" надо писать не на языке . а с использованием языка. твои is_array хороший пример программирования на языке. прочти эту книгу и у тебя сразу отпадут вопросы про ооп.
ясно дело, что всё сэйвится виде "длинюющей строки". только строка особого формата, чтоб можно было распарсить в то-то или в то-то. ведь надо как-то с ней потом работать. JSON / XML очень спасают =) в нашем примере юзается JSON. его очень удобно парсить в объект, например (ну, для жаваскрипта это мегаудобно, ибо получаешь готовую коллекцию =))) , либо в массив. как душе пожелается)
