Developpez.com

Le Club des Développeurs et IT Pro

PHP : la programmation orientée objet réinventée ?

Un hack permet de manipuler les objets comme en JavaScript

Le 2010-09-24 12:36:32, par Idelways, Expert éminent sénior
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 : 
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
  Discussion forum
26 commentaires
  • 10_GOTO_10
    Membre expérimenté
    [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]
    le 24/09/2010 à 14:54
  • palnap
    Membre averti
    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?
    le 24/09/2010 à 16:24
  • Idelways
    Expert éminent sénior
    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
    le 24/09/2010 à 16:36
  • gorgonite
    Rédacteur/Modérateur
    classe vs prototype... éternel débat depuis l'origine de la POO

    petite description
    le 24/09/2010 à 18:12
  • aurelman
    Membre actif
    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 : 
    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.
    le 24/09/2010 à 15:58
  • yann2
    Membre expérimenté
    Envoyé par Idelways
    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.
    le 24/09/2010 à 17:13
  • bubulemaster
    Membre éclairé
    Envoyé par Idelways

    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.
    le 24/09/2010 à 12:56
  • Klaim
    Membre expert
    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.
    le 24/09/2010 à 13:13
  • huit_six
    Membre actif
    @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 !
    le 24/09/2010 à 13:44
  • naholyr
    Membre régulier
    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.
    le 24/09/2010 à 13:52
  Poster une réponse