Pourquoi renvoyer un objet au lieu d'un tableau ?

Question

Je travaille beaucoup avec WordPress, et j'ai remarqué que beaucoup plus de fonctions renvoient des objets que des tableaux. Les résultats des bases de données sont retournés sous forme d'objets, sauf si vous demandez spécifiquement un tableau. Les erreurs sont retournées sous forme d'objets. En dehors de WordPress, la plupart des APIs vous donnent un objet au lieu d'un tableau.

Ma question est la suivante : pourquoi utilisent-ils des objets au lieu de tableaux ? Dans la plupart des cas, cela n'a pas trop d'importance, mais dans certains cas, je trouve les objets plus difficiles à traiter et à comprendre. Y a-t-il une raison de performance pour utiliser un objet ?

Je suis un programmeur PHP autodidacte. J'ai un diplôme d'arts libéraux. Alors pardonnez-moi si un aspect fondamental de l'informatique me manque ;)

Answer 1

Ce sont les raisons pour lesquelles je préfère les objets en général :

• Les objets ne contiennent pas seulement des données mais aussi des fonctionnalités.
• Les objets ont (dans la plupart des cas) une structure prédéfinie. Cela est très utile pour la conception d'API. En outre, vous pouvez définir les propriétés comme publiques, protégées ou privées.
• les objets correspondent mieux au développement orienté objet.
• Dans la plupart des IDE, l'autocomplétion ne fonctionne que pour les objets.

Voici quelque chose à lire :

• Objet et tableau en PHP
• PHP stdClass : Stocker des données dans un objet plutôt que dans un tableau
• Quand dois-je utiliser stdClass et quand dois-je utiliser un tableau dans le code php5 oo ?
• Objets PHP et tableaux
• Résultats Mysql en PHP - tableaux ou objets ?
• Mythe des performances des objets PHP par rapport aux tableaux
• Un ensemble d'objets en PHP : Tableaux et SplObjectStorage
• De meilleurs tableaux orientés objet

Answer 2

Ce n'est probablement pas quelque chose que vous comprendrez profondément avant d'avoir travaillé sur un grand projet logiciel pendant plusieurs années. De nombreux jeunes diplômés en informatique vous donneront une réponse avec tous les mots justes (encapsulation, fonctionnalité avec les données et maintenabilité), mais peu d'entre eux comprendront vraiment pourquoi tout cela est bon à avoir.

Voyons quelques exemples.

• Si des tableaux sont renvoyés, soit toutes les valeurs doivent être calculées dès le départ, soit il faut renvoyer un grand nombre de petites valeurs à partir desquelles on peut construire des valeurs plus complexes.

Pensez à une méthode API qui renvoie une liste d'articles WordPress. Ces articles ont tous des auteurs, les auteurs ont des noms, des adresses e-mail, peut-être même des profils avec leurs biographies.

Si vous renvoyez tous les messages dans un tableau, vous devrez vous limiter à renvoyer un tableau d'identifiants de messages :

[233, 41, 204, 111]

ou renvoyer un tableau massif qui ressemble à quelque chose comme :

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

Le premier cas, qui consiste à renvoyer une liste d'identifiants, n'est pas très utile, car vous devez alors effectuer un appel API pour chaque identifiant afin d'obtenir des informations sur ce message.

Dans le second cas, vous obtiendrez beaucoup plus d'informations que ce dont vous avez besoin dans 90 % des cas et vous aurez beaucoup plus de travail (surtout si l'un de ces champs est très compliqué à construire).

Un objet, quant à lui, peut vous permettre d'accéder à toutes les informations dont vous avez besoin, mais sans les avoir réellement extraites. La détermination des valeurs des champs peut se faire de manière paresseuse (c'est-à-dire lorsque la valeur est nécessaire et non à l'avance) lorsqu'on utilise un objet.

• Les tableaux exposent plus de données et de capacités que prévu.

Revenez à l'exemple du tableau massif retourné. Maintenant, quelqu'un peut probablement construire une application qui itère sur chaque valeur du tableau de messages et l'imprime. Si l'API est mise à jour pour ajouter un seul élément supplémentaire à ce tableau de messages, le code de l'application va s'interrompre car il va imprimer un nouveau champ qu'il ne devrait probablement pas. Si l'ordre des éléments du tableau de messages renvoyé par l'API change, le code de l'application sera également perturbé. Le renvoi d'un tableau crée donc toutes sortes de dépendances possibles qu'un objet ne créerait pas.

• Fonctionnalité

Un objet peut contenir des informations qui lui permettront de vous fournir des fonctionnalités utiles. Un objet post, par exemple, pourrait être assez intelligent pour renvoyer les messages précédents ou suivants. Un tableau ne pourrait jamais faire cela pour vous.

• Flexibilité

Tous les avantages des objets mentionnés ci-dessus contribuent à créer un système plus flexible.

Answer 3

Ma question est la suivante : pourquoi utilisent-ils des objets au lieu de tableaux ?

Probablement deux raisons :

• WordPress est assez vieux
• Les tableaux sont plus rapides et prennent moins de mémoire dans la plupart des cas.
• plus facile à sérialiser

Y a-t-il une raison de performance pour utiliser un objet ?

Non. Mais beaucoup d'autres bonnes raisons, par exemple :

• vous pouvez stocker la logique dans les objets (méthodes, fermetures, etc.)
• vous pouvez forcer la structure de l'objet en utilisant un interface
• meilleure autocomplétion dans l'IDE
• vous n'obtenez pas d'avis pour les clés de tableau non-définies
• au final, vous pouvez facilement convertir n'importe quel objet en tableau

OOP != AOP :)

(Par exemple, en Ruby, tout est un objet. Auparavant, PHP était un langage procédural/scriptural).

Answer 4

WordPress (et un bon nombre d'autres applications PHP) utilise des objets plutôt que des tableaux, pour des raisons conceptuelles plutôt que techniques.

Un objet (même si ce n'est qu'une instance de stdClass) est une représentation d'une chose. Dans WordPress, cela peut être un article, un commentaire, ou un utilisateur. Un tableau, d'un autre côté, est une collection de choses. (Par exemple, une liste d'articles).

Historiquement, PHP n'a pas eu un grand support des objets, donc les tableaux sont devenus assez puissants très tôt. (Par exemple, la possibilité d'avoir des clés arbitraires plutôt que d'être simplement indexé à zéro). Avec le support des objets disponible en PHP 5, les développeurs ont maintenant le choix entre l'utilisation de tableaux ou d'objets comme stockage de valeurs clés. Personnellement, je préfère l'approche de WordPress car j'aime la différence syntaxique entre "entités" et "collections" que les objets et les tableaux fournissent.

Answer 5

Ma question est la suivante : pourquoi (Wordpress) utilise-t-il des objets au lieu de tableaux ?

C'est vraiment une bonne question à laquelle il n'est pas facile de répondre. Je ne peux que supposer qu'il est courant dans Wordpress d'utiliser stdClass parce qu'ils utilisent une classe de base de données qui, par défaut, renvoie les enregistrements sous la forme d'objets stdClass objet. Ils s'y sont habitués (8 ans et plus) et c'est tout. Je ne pense pas qu'il y ait beaucoup plus de réflexion derrière ce simple fait.

sucre syntaxique pour les tableaux associatifs -- Zeev Suraski à propos de l'objet standard depuis PHP 3

• stdClass les objets ne sont pas vraiment meilleurs que les tableaux. Ils sont à peu près identiques. C'est pour des raisons historiques du langage ainsi que pour des raisons de sécurité. stdClass les objets sont vraiment limités et ne sont en fait qu'une sorte de objets de valeur dans un sens très élémentaire.
• stdClass Les objets stockent les valeurs de leurs membres comme le fait un tableau par entrée. Et c'est tout.
• Seuls les fous de PHP sont capables de créer stdClass les objets avec les membres privés. Il n'y a pas beaucoup d'avantages - voire aucun - à le faire.
• stdClass les objets n'ont pas de méthodes/fonctions. Ils ne peuvent donc pas être utilisés dans Wordpress.
• Par rapport à array il existe des fonctions beaucoup moins utiles pour traiter une liste ou des données semi-structurées.

Cependant, si vous êtes habitué aux tableaux, il suffit de faire un casting :

$array = (array) $object;

Et vous pouvez accéder aux données en étant auparavant un objet, comme un tableau. Ou bien vous préférez l'inverse :

$object = (object) $array;

Ce qui n'éliminera que les noms de membres invalides, comme les numéros. Il faut donc faire attention. Mais je pense que vous avez compris le tableau d'ensemble : Il n'y a pas beaucoup de différence tant qu'il s'agit de tableaux et d'objets de type stdClass .

En rapport :

• Conversion en objet Manuel PHP
• Classes réservées Manuel PHP
• Qu'est-ce que stdClass en PHP ?