Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

PHP : la programmation orientée objet réinventée ?
Un hack permet de manipuler les objets comme en JavaScript

Le , par Idelways

0PARTAGES

0  0 
Visiblement non satisfait par les limitations du modèle objet de PHP, le développeur Dennis Hotson a créé un « Hack » permettant de manipuler les objets comme en JavaScript ou en Ruby.

Son bout de code (plutôt simple) est encore très expérimental et ne fonctionne que sous PHP 5.3.x car il s'appuie essentiellement sur les closures introduites dans la branche 5.3.

Ses implications sont très intéressantes, car il offre des possibilités de méta-programmation et de « monkey-patching » jusque-là non-accessibles comme l'ouverture, la modification et le clonage des classes et l'ajout des méthodes à n'importe quel moment de l'exécution du code.

Selon Dennis, son hack permettrait aussi de limiter la portée des classes et rendre certaines classes temporaires pouvant être débarrassés par le ramasse-miettes.

Son usage ressemblerait à cela :

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
// Définir une nouvelle classe avec un constructeur et une méthode
$animal = $class->new()
  ->def('init', function($t, $name) {
    $t->name = $name;
  })
  ->def('speak', function($t) {
    echo "My name is $t->name\n";
  });

// Etendre la classe en ajoutant une autre méthode
$dog = $animal->extend()
  ->def('speak', function($t) {
      echo "My name is $t->name, I have just met you and I love you, SQUIRREL!\n";
  })
  ->def('bark', function($t) {
      echo "Woof!\n";
  });
Mais son idée soulève des interrogations sur la pertinence de sa démarche.

Certains blogueurs applaudissent mais d'autres qualifient son bout de code de « bricolage » et l'invitent plutôt à changer de langage.

Son code est disponible sur GitHub.

Et vous ?

Qu'en pensez-vous ? « Bricolage » inutile ou « invention » vraiment intéressante ?
Et d'une manière générale, que reprochez-vous au modèle objet de PHP ?

Source : Le Blog de Dennis Hotson

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de 10_GOTO_10
Membre expérimenté https://www.developpez.com
Le 24/09/2010 à 14:54
[humour]
Zut ! J'ai dû cliquer à coté, je suis dans le post "le pire bout de code que vous avez vu"... Ah ben non, je suis bien dans le forum "actualités" ?

Non, là vous exagérez. Déjà du PHP normalement bien implémenté, ça pique les yeux, mais là, franchement, non, si je me réveille en sueur cette nuit, ce sera votre faute ! Que font les modérateurs, ça devrait être interdit, un poste comme ça!
[/humour]
2  0 
Avatar de palnap
Membre actif https://www.developpez.com
Le 24/09/2010 à 16:24
C'est dingue de voir autant de réactions négatives, moi je trouve que tout ce qui tend à dynamiser un langage est bon à prendre... Après selon le "style" du programmeur, ça peut être utile ou non, mais je pense que le paradigme fonctionnel apporte des choses très intéressantes et il me semble que c'est profitable à tous de voir apparaitre ces notions dans les derniers langages à la mode (.NET avec les closures, Java prochainement, ...)

Quand l'implémentation des closures en Java sera terminée, ça vous piquera autant les yeux?
2  0 
Avatar de Idelways
Expert éminent sénior https://www.developpez.com
Le 24/09/2010 à 16:36
Bonjour,

Merci d'avoir évoqué l'exemple de Ruby Aurelpitiless.

Un exemple de génération à la volée des méthodes en Rails est sur Active Record:

Pour chaque colonne de la table, l'ORM créé plusieurs méthodes. Pour un modèle Client, il regarde dans le schéma de la base et trouve par exemple une colonne phone_number, alors il ajoute à la classe Client des méthodes client.phone_number pour retourner le numéro de téléphone, la méthode d'assignation client.phone_numer= pour le modifier et client.phone_number? qui retourne True si le client a renseigné son numéro de téléphone.

C'est quand même plus sexy que de faire !empty($client.attributes['phone_number']) ou de créer soit même manuellement des méthodes par colonnes et entretenir tout ce bazar à chaque changement de schémas comme j'en ai vu sur des ORM .NET.

D'ailleurs, sans cela, je ne crois pas que l'application du pattern Convention plutôt que configuration soit aisée, voir même possible sur certains cas.

Par ailleurs, la possibilité d'ouvrir des classes est très puissante, par exemple si une faille critique est détectée dans un framework donné, on peut la patcher soit même soit en corrigeant la ou les méthodes incriminées, ou les désactiver en supprimant la méthode en attendant un correctif.

A partir de là, les applications sont illimitées pour ce genre de manipulations et on peut faire pratiquement tout.

Mais je vous accorde le l'usage du monkey patching soit plus utile dans le cadre du développement d'un framework ou une librairie générique, son usage par le "développeur final" peut être facilement évité.

Cordialement
Idelways
2  0 
Avatar de gorgonite
Rédacteur/Modérateur https://www.developpez.com
Le 24/09/2010 à 18:12
classe vs prototype... éternel débat depuis l'origine de la POO

petite description
2  0 
Avatar de aurelman
Membre actif https://www.developpez.com
Le 24/09/2010 à 15:58
Bonjour,

Rajouter des methodes à la volée à une classe (voir même à un objet) peut avoir un interêt.

C'est ce qui permet dans le monde ruby par exemple, au framework Rails de rajouter des méthodes à la classe des entier pour pouvoir écrire des choses comme :
Code : Sélectionner tout
veille = 1.day.ago

pour récupérer un objet Date qui pointe sur la veille.
Plus lisible non ? Et pas besoin de se farcir une hierarchie de classe juste pour une bête fonctionalité.

Bien sur en PHP les entiers ne sont pas de vrais objets mais c'est pour expliquer le principe...

Après il faut l'utiliser a bon escient hein ! Faut pas en faire n'importe quoi.
1  0 
Avatar de yann2
Membre expérimenté https://www.developpez.com
Le 24/09/2010 à 17:13
Citation Envoyé par Idelways Voir le message
Bonjour,

Merci d'avoir évoqué l'exemple de Ruby Aurelpitiless.

Un exemple de génération à la volée des méthodes en Rails est sur Active Record:

Pour chaque colonne de la table, l'ORM créé plusieurs méthodes. Pour un modèle Client, il regarde dans le schéma de la base et trouve par exemple une colonne phone_number, alors il ajoute à la classe Client des méthodes client.phone_number pour retourner le numéro de téléphone, la méthode d'assignation client.phone_numer= pour le modifier et client.phone_number? qui retourne True si le client a renseigné son numéro de téléphone.

C'est quand même plus sexy que de faire !empty($client.attributes['phone_number']) ou de créer soit même manuellement des méthodes par colonnes et entretenir tout ce bazar à chaque changement de schémas comme j'en ai vu sur des ORM .NET.

D'ailleurs, sans cela, je ne crois pas que l'application du pattern Convention plutôt que configuration soit aisée, voir même possible sur certains cas.

Par ailleurs, la possibilité d'ouvrir des classes est très puissante, par exemple si une faille critique est détectée dans un framework donné, on peut la patcher soit même soit en corrigeant la ou les méthodes incriminées, ou les désactiver en supprimant la méthode en attendant un correctif.

A partir de là, les applications sont illimitées pour ce genre de manipulations et on peut faire pratiquement tout.

Mais je vous accorde le l'usage du monkey patching soit plus utile dans le cadre du développement d'un framework ou une librairie générique, son usage par le "développeur final" peut être facilement évité.

Cordialement
Idelways
Ce genre de choses est effectivement pratique pour construire une structure de données à partir d'une source de données (xml, base de données, ...).

Cependant, cela est déjà faisable [en PHP] sans avoir besoin d'ajouter des méthodes à une classe (ni même avoir besoin de créer une "nouvelle" classe, oui nouvelle entre guillemets parce que si vous regardez le code, on a juste des instances de Obj).

Bref, je n'appelle pas ça "inventer". L'interception d'invocations de méthodes avec la méthode __call existe depuis belle lurette (avant les closures). En fait, l'emploi des closures dans l'exemple ne fait qu'ajouter de l'illisibilité dans le code.

Vous l'aurez compris : pas convaincu - du tout - par ce bout de code. Pour moi, ça reste de la masturbation intellectuel.

Toutefois, l'interception des appels avec la méthode __call restes une possibilité très intéressante.
1  0 
Avatar de bubulemaster
Membre confirmé https://www.developpez.com
Le 24/09/2010 à 12:56
Citation Envoyé par Idelways Voir le message

l'ajout des méthodes à n'importe quel moment de l'exécution du code.
Je l'invite à maintenir un application où on rajoute des méthodes à la volé. Il verra que c'est inmaintenable et que le projet va couler.
J'en ai fait l'expérience en JavaScript sur un grosse application.
Du coup, c'est bug sur bug et la facture du client explose et celui-ci arrêt carrément le projet.
En plus, pour moi (et d'autre avec qui j'en ai discuté) la possibilité de rajouter une méthode à la volé va à l'encontre de l'objet.
La notion d'objet en informatique est la même que la vie courrante. Or, comme dans la vie, si on rajoute des morceaux comme ça, au bout d'un moment l'objet devient fragile et même dangereux.

De plus, cette technique montre clairement un problème d'analyse/conception.
0  0 
Avatar de Klaim
Membre expert https://www.developpez.com
Le 24/09/2010 à 13:13
Le Monkey-Patching, c'est comme les templates : c'est puissant mais du cout ça doit être craint et respecté pour pas être utilisé à tort et à travers. C'est aussi très facile a mal utiliser.
0  0 
Avatar de huit_six
Membre actif https://www.developpez.com
Le 24/09/2010 à 13:44
@Klaim : C'est marrant, on peut dire la même chose des pointeurs en C.

Plus concrètement, personnellement je trouve que c'est atroce l'ajout des méthodes à la volée, ça fait qu'à aucun moment dans le code, on ne peut être sûr de la structure réelle de l'objet en question. J'ai déjà essayé de comprendre un projet qui faisait ce genre de chose et franchement, il me restait bien moins de cheveux après qu'avant...
D'autant plus qu'en général ça ne se justifie pas du tout !
0  0 
Avatar de naholyr
Membre régulier https://www.developpez.com
Le 24/09/2010 à 13:52
Totalement bidon, et en plus c'est vu et revu (sans les closures on le faisait aussi bien en passant le nom d'une fonction et call_user_func_array()).

Après de là à dire que cette technique est bancale : non, je pense au contraire que si on a *besoin* d'une technique de ce genre, c'est justement que le projet lui-même est bancal dès le départ. Après l'œuf qui fait la poule ou la poule qui fait l'œuf tout ça... Que ce soit le symptôme à la maladie, en tous cas cette technique est à fuir.

En Javascript je m'en passe très bien, à part si je dois vraiment écrire un framework qui simplifie certaines choses (en ajoutant par exemple String.prototype.startsWith ou autres choses de ce genre), et qui soit clairement documenté. Hors de ce cas très particulier (qui vient compléter une API lacunaire), point de salut pour cette technique.
0  0