Подтвердить что ты не робот

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

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

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

Я программист PHP. У меня степень либерального искусства. Так что простите меня, если я упустил фундаментальный аспект информатики.;)

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

Пропустим несколько примеров.

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

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

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

[233, 41, 204, 111]

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

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

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

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

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

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

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

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

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

  • Гибкость

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

Ответ 3

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

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

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

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

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

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

OOP!= AOP:)

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

Ответ 4

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

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

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

Ответ 5

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

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

синтаксический сахар для ассоциативных массивов - Zeev Suraski о стандартном объекте с PHP 3

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

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

$array = (array) $object;

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

$object = (object) $array;

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

Связанный:

Ответ 6

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

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

Ответ 7

  • Код выглядит более круто таким образом
  • Объекты проходят по ссылке
  • Объекты более сильные, а затем массивы, поэтому lees pron to errors (или дает вам осмысленное сообщение об ошибке при попытке использовать несуществующий элемент)
  • Все IDE сегодня имеют автоматическое завершение, поэтому при работе с определенными объектами среда ID делает много для вас и ускоряет работу.
  • Легко инкапсулировать логические и данные в том же поле, где с массивами, вы храните данные в массиве, а затем используйте набор различных функций для его обработки.
  • Наследование. Если бы у вас был подобный массив с почти, но не похожей функциональностью, вам пришлось бы дублировать больше кода, если вы хотите сделать это с помощью объектов

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

Ответ 8

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

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

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

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

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

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

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

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

Ответ 9

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

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

Ответ 10

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

$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.

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

Ответ 11

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

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

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

Ответ 12

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

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

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

Ответ 13

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).

Ответ 14

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

Ответ 15

Хотя точки, сделанные об объектах больше, чем просто данные, являются действительными, поскольку они обычно являются данными и поведением, по крайней мере один шаблон, упомянутый в Martin Fowler "Шаблоны" Архитектура прикладных приложений", которая применяется к этому типу cenario, в котором вы переносите данные из одной системы (приложение за API) и другое (ваше приложение).

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

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