Зачем возвращать объект вместо массива?

Вот почему я предпочитаю объекты в целом:

• Объекты не только содержат данные, но и функциональность.
• Объекты имеют (в большинстве случаев) предопределенную структуру. Это очень полезно для проектирования API. Кроме того, вы можете устанавливать свойства как общедоступные, защищенные или частные.
• объекты лучше подходят для объектно-ориентированного развития.
• В большинстве автозавершений IDE работает только для объектов.

Вот что можно прочитать:

• Объект Vs. Массив в PHP
• PHP stdClass: сохранение данных в объекте вместо массива
• Когда следует использовать stdClass и когда я должен использовать массив в php5 oo code
• Объекты PHP против массивов
• Mysql приводит к PHP-массивам или объектам?
• PHP-объекты против мифа
• Набор объектов в PHP: массивы и SplObjectStorage
• Улучшенные объектно-ориентированные массивы

Вероятно, это не то, что вы глубоко понимаете, пока не будете работать над крупным программным проектом в течение нескольких лет. Многие новые специалисты в области информатики дадут вам ответ со всеми правильными словами (инкапсуляция, функциональность с данными и ремонтопригодность), но мало кто действительно поймет, почему все это хорошо.

Давайте рассмотрим несколько примеров.

• Если массивы были возвращены, то либо все значения должны быть вычислены заранее, либо нужно вернуть много маленьких значений, из которых вы можете построить более сложные значения.

Подумайте о методе API, который возвращает список сообщений WordPress. У этих должностей есть авторы, авторы имеют имена, адрес электронной почты, возможно, даже профили с их биографиями.

Если вы возвращаете все сообщения в массиве, вам придется либо ограничить себя возвратом массива почтовых идентификаторов:

[233, 41, 204, 111]

или возвращает массивный массив, который выглядит примерно так:

 [ title: 'somePost', body: 'blah blah', 'author': ['name': 'billy', 'email': 'bill@bill.com', 'profile': ['interests': ['interest1', 'interest2', ...], 'bio': 'info...']] ] [id: '2', .....]] 

Первый случай возврата списка идентификаторов не очень полезен для вас, потому что тогда вам нужно сделать вызов API для каждого идентификатора, чтобы получить некоторую информацию об этом сообщении.

Второй случай доставит больше информации, чем вам понадобится 90% времени, и будет делать больше работы (особенно, если какое-либо из этих полей очень сложно построить).

Объект, с другой стороны, может предоставить вам доступ ко всей необходимой вам информации, но пока не на самом деле вытащил эту информацию. Определение значений полей может производиться лениво (т. Е. Когда значение необходимо, а не заранее) при использовании объекта.

• Массивы предоставляют больше данных и возможностей, чем предполагалось

Вернемся к примеру массивного массива, который возвращается. Теперь кто-то, вероятно, может создать приложение, которое выполняет итерацию по каждому значению внутри массива post и печатает его. Если API обновлен, чтобы добавить только один дополнительный элемент в этот пост-массив, тогда код приложения собирается сломаться, так как он будет печатать новое поле, которое, вероятно, не должно. Если порядок элементов в массиве сообщений, возвращаемых API, изменится, это также нарушит код приложения. Поэтому возвращение массива создает всевозможные зависимости, которые объект не создавал.

• функциональность

Объект может содержать информацию внутри него, которая позволит ему предоставить вам полезные функции. Например, объект post может быть достаточно умным, чтобы возвращать предыдущие или следующие сообщения. Массив не мог сделать это для вас.

• гибкость

Все преимущества упомянутых выше объектов помогают создать более гибкую систему.

Мой вопрос в том, почему они используют объекты вместо массивов?

Вероятно, две причины:

• WordPress довольно старый
• массивы быстрее и требуют меньше памяти в большинстве случаев
• проще сериализовать

Есть ли причина использования для использования объекта?

Нет. Но есть много хороших других причин, например:

• вы можете хранить логику в объектах (методы, закрытие и т. д.),
• вы можете заставить структуру объекта использовать интерфейс
• лучшее автозаполнение в среде IDE
• вы не получаете уведомления о непредельных ключах массива
• в конце концов, вы можете легко преобразовать любой объект в массив

ООП ! = АОП 🙂

(Например, в Ruby все является объектом. PHP ранее был языком процедур / скриптов.)

WordPress (и значительное количество других приложений PHP) использует объекты, а не массивы, для концептуальных, а не технических соображений.

Объект (даже если только экземпляр stdClass) является представлением одной вещи. В WordPress это может быть сообщение, комментарий или пользователь. Массив, с другой стороны, представляет собой набор вещей. (Например, список сообщений.)

Исторически сложилось так, что PHP не обладал большой поддержкой объектов, поэтому массивы стали достаточно мощными на ранней стадии. (Например, возможность иметь произвольные ключи, а не просто индексировать с нулевой отметкой.) Благодаря поддержке объектов, доступной в PHP 5, разработчикам теперь предоставляется выбор между использованием массивов или объектов в качестве хранилищ для ключей. Лично я предпочитаю подход WordPress, поскольку мне нравится синтаксическая разница между «сущностями» и «коллекциями», которые предоставляют объекты и массивы.

Мой вопрос: почему они (WordPress) используют объекты вместо массивов?

Это действительно хороший вопрос и нелегко ответить. Я могу только предположить, что в WordPress распространено использование объектов stdClass потому что они используют класс базы данных, который по умолчанию возвращает записи как объект stdClass . Они привыкли к этому (8 лет и более), и все. Я не думаю, что за простым фактом гораздо больше внимания.

синтаксический сахар для ассоциативных массивов – Зеев Сураски о стандартном объекте с PHP 3

• Объекты stdClass самом деле не лучше массивов. Они почти одинаковы. Это stdClass некоторыми историческими причинами языка, а также с объектами stdClass которые действительно ограничены и фактически представляют собой только объекты с ценностями в очень базовом смысле.
• Объекты stdClass хранят значения для своих членов, как массив для каждой записи. Вот и все.
• Только PHP freaks могут создавать объекты stdClass с частными членами. Не так много пользы – если таковые имеются – делаю это.
• stdClass объектов stdClass нет никаких методов / функций. Так что не используйте это в WordPress.
• По сравнению с array гораздо менее полезны функции для обработки списка или полуструктурированных данных.

Однако, если вы привыкли к массивам, просто нажмите:

 $array = (array) $object; 

И вы можете получить доступ к данным, ранее являющимся объектом, в качестве массива. Или вам нравится наоборот:

 $object = (object) $array; 

Который приведет только к недопустимым именам участников, например числам. Поэтому немного позаботьтесь. Но я думаю, вы получите большую картину: нет большой разницы, если речь идет о массивах и объектах stdClass .

Связанный:

• Преобразование в объект ^{PHP Manual}
• Зарезервированные классы ^{Руководство по PHP}
• Что такое stdClass в PHP?

1. Код выглядит более крутым
2. Объекты проходят по ссылке
3. Объекты более сильные, а затем массивы, поэтому lees произносится до ошибок (или дает вам осмысленное сообщение об ошибке при попытке использовать несуществующий элемент)
4. Все IDE сегодня имеют автозаполнение, поэтому при работе с определенными объектами среда ID делает много для вас и ускоряет работу
5. Easilly инкапсулирует логику и данные в том же поле, где с массивами вы храните данные в массиве, а затем используете набор различных функций для его обработки.
6. Наследование. Если бы у вас был подобный массив с почти, но не похожими функциональными возможностями, вам пришлось бы дублировать больше кода, если вы хотите сделать это с помощью объектов

Вероятно, еще одна причина, по которой я думал

Объекты намного мощнее, чем массивы. Каждый объект как экземпляр класса может иметь прикрепленные функции. Если у вас есть данные, требующие обработки, вам нужна функция, которая выполняет обработку. С помощью массива вам придется вызывать эту функцию на этом массиве и, следовательно, связывать логику с данными. С объектом эта ассоциация уже выполнена, и вам больше не нужно ее заботиться.

Также вы должны рассмотреть принцип скрытности информации OO. Не все, что возвращается или поступает в базу данных, должно быть доступно напрямую.

Есть несколько причин возвращать объекты:

1. Написание $myObject->property требует меньше «служебных» символов, чем $myArray['element']

2. Объект может возвращать данные и функциональные возможности; массивы могут содержать только данные.

3. Включить цепочку: $myobject->getData()->parseData()->toXML();

4. Более легкое кодирование: автозаполнение IDE может предоставлять подсказки метода и свойств для объекта.

С точки зрения производительности массивы часто бывают быстрее, чем объекты. В дополнение к производительности, есть несколько причин использовать массивы:

1. Функциональность, предоставляемая семейством функций массива _ * (), может уменьшить количество кодирования, необходимое в некоторых случаях.

2. Такие операции, как count () и foreach (), могут выполняться на массивах. Объекты не предлагают этого (если они не реализуют Iterator или Countable ).

Как правило, это не связано с соображениями производительности. Как правило, объекты стоят больше, чем массивы.

Для многих API-интерфейсов это, вероятно, связано с объектами, предоставляющими другие функции, помимо механизма хранения. В противном случае это вопрос предпочтения, и нет никакой выгоды для возвращения объекта и массива.

Массив – это всего лишь индекс значений. В то время как объект содержит методы, которые могут генерировать результат для вас. Конечно, иногда вы можете напрямую обращаться к значениям объектов, но «правильный способ сделать это» – это доступ к методам объектов (функция, действующая на значения этого объекта).

 $obj = new MyObject; $obj->getName(); // this calls a method (function), so it can decide what to return based on conditions or other criteria $array['name']; // this is just the string "name". there is no logic to it. 

Иногда вы напрямую обращаетесь к объектным переменным, обычно это недовольно, но это происходит довольно часто.

 $obj->name; // accessing the string "name" ... not really different from an array in this case. 

Однако учтите, что класс MyObject не имеет переменной с именем 'name', но вместо этого имеет переменную first_name и last_name.

 $obj->getName(); // this would return first_name and last_name joined. $obj->name; // would fail... $obj->first_name; $obj->last_name; // would be accessing the variables of that object directly. 

Это очень простой пример, но вы можете видеть, где это происходит. Класс предоставляет набор переменных и функции, которые могут работать с этими переменными, все в пределах автономного логического объекта. Экземпляр этого объекта называется объектом, и он вводит логические и динамические результаты, которых у массива просто нет.

Большинство объектов времени так же быстро, если не быстрее, чем массивы, в PHP нет заметной разницы. основная причина в том, что объекты более мощные, чем массивы. Программное обеспечение, ориентированное на объекты, позволяет создавать объекты и хранить не только данные, но и функциональность в них, например, в PHP. Класс MySQLi позволяет вам иметь объект базы данных, с которым вы можете манипулировать, используя множество встроенных функций, а не процедурный подход.

Поэтому основная причина заключается в том, что ООП – отличная парадигма. Я написал статью о том, почему использование ООП является хорошей идеей и объясняет концепцию, вы можете посмотреть здесь: http://tomsbigbox.com/an-introduction-to-oop/

В качестве второстепенного плюса вы также вводите меньше, чтобы получить данные из объекта – данные $ test-> лучше, чем $ test ['data'].

Я не знаком с прессой. Многие ответы здесь показывают, что в силе объектов есть возможность содержать функциональный код. При возврате объекта из вызова функции / API он не должен содержать служебных функций. Просто свойства.

Сила в возвращаемых объектах заключается в том, что все, что находится за API, может измениться без нарушения кода.

Пример. Вы получаете массив данных с парами ключ / значение, представляющий столбец БД. Если столбец DB будет переименован, ваш код сломается.

Im запускает следующий тест в php 5.3.10 (windows):

 for ($i = 0; $i < 1000000; $i++) { $x = array(); $x['a'] = 'a'; $x['b'] = 'b'; } 

а также

 for ($i = 0; $i < 1000000; $i++) { $x = new stdClass; $x->a = 'a'; $x->b = 'b'; } 

Скопировано из http://atomized.org/2009/02/really-damn-slow-a-look-at-php-objects/comment-page-1/#comment-186961

Вызов функции для 10 одновременных пользователей и 10 раз (для получения среднего значения)

• Массивы: 100%
• Объект: 214% – 216% (в 2 раза медленнее).

AKA, Object это все еще болезненно медленно. ООП сохраняет порядок вещей, однако его следует использовать осторожно.

Что WordPress применяет ?. Ну, оба решения, использует объекты, массивы и объекты и массивы, класс wpdb использует позже (и это сердце WordPress).

Он следует принципу бокса и распаковки ООП. Хотя языки, такие как Java и C #, поддерживают это изначально, PHP нет. Однако это может быть достигнуто, в некоторой степени, в PHP, просто не красноречиво, поскольку сам язык не имеет конструкций для его поддержки. Наличие типов полей в PHP может помочь в цепочке, сохраняя все объектно-ориентированное и позволяя вводить тип в сигнатурах метода. Недостаток – это накладные расходы и тот факт, что теперь у вас есть дополнительная проверка, использующая конструкцию. Наличие системы типов также является плюсом при использовании инструментов разработки, которые имеют intellisense или код, например PDT. Вместо того, чтобы использовать метод google / bing / yahoo для этого метода, он существует на объекте, и вы можете использовать этот инструмент, чтобы обеспечить раскрывающийся список.

Хотя точки, связанные с объектами, больше, чем просто данные, являются действительными, поскольку они обычно являются данными и поведением, по крайней мере, один шаблон, упомянутый в «Шаблонах архитектуры корпоративных приложений» Мартина Фаулера, который применяется к этому типу центра, в котором вы переносите данные из одной системы (приложение за API) и другое (ваше приложение).

Его объект передачи данных – объект, который переносит данные между процессами, чтобы уменьшить количество вызовов методов.

Поэтому, если вопрос заключается в том, должны ли API-интерфейсы возвращать DTO или массив, я бы сказал, что если стоимость производительности незначительна, тогда вы должны выбрать опцию, которая более удобна в обслуживании, о которой я бы сказал, это опция DTO … но, конечно, вы также должны учитывать навыки и культуру команды, которая разрабатывает вашу систему и язык или поддержку IDE для каждого из вариантов.