Content-type: text/html
Ici nous utiliserons une approche différente en supposant que vous n'avez aucune expérience préalable avec l'objet. Il est quand même souhaitable de connaître les subroutines (perlsub), les références (perlref et autres) et les packages (perlmod). Essayez de vous familiariser avec ces concepts si vous ne l'avez pas déjà fait.
pub Boeuf::fait { print "un Boeuf fait mheuu !\n"; } sub Cheval::fait { print "un Cheval fait hiiii !\n"; } sub Mouton::fait { print "un Mouton fait bêêê !\n" }
Boeuf::fait; Cheval::fait; Mouton::fait;
Le résultat sera :
un Boeuf fait mheuu ! un Cheval fait hiiii ! un Mouton fait bêêê !
Ici, rien de spectaculaire. De simples subroutines, bien que dans des packages séparés, appelées en utilisant leur nom complet (incluant le nom du package). Créons maintenant un troupeau :
# Boeuf::fait, Cheval::fait, Mouton::fait comme au-dessus @troupeau = qw(Boeuf Boeuf Cheval Mouton Mouton); foreach $animal (@troupeau) { &{$animal."::fait"}; }
Le résultat sera :
un Boeuf fait mheuu ! un Boeuf fait mheuu ! un Cheval fait hiiii ! un Mouton fait bêêê ! un Mouton fait bêêê !
Super. Mais l'utilisation de références symboliques vers les subroutines "fait" est un peu déplaisante. Nous comptons sur le mode "no strict subs" ce qui n'est certainement pas recommandé pour de gros programmes. Et pourquoi est-ce nécessaire ? Parce que le nom du package semble inséparable du nom de la subroutine que nous voulons appeler dans ce package.
# Boeuf::fait, Cheval::fait, Mouton::fait comme au-dessus Boeuf->fait; Cheval->fait; Mouton->fait;
À nouveau, le résultat sera :
un Boeuf fait mheuu ! un Cheval fait hiiii ! un Mouton fait bêêê !
Ce n'est pas encore super : même nombre de caractères, que des constantes, pas de variables. Mais maintenant, on peut séparer les choses :
$a = "Boeuf"; $a->fait; # appelle Boeuf->fait
Ah ! Maintenant que le nom du package est séparé du nom de la subroutine, on peut utiliser un nom de package variable. Et cette fois, nous avons quelque chose qui marche même lorsque "use strict refs" est actif.
sub Boeuf::fait { print "un Boeuf fait mheuu !\n"; } sub Cheval::fait { print "un Cheval fait hiiii !\n"; } sub Mouton::fait { print "un Mouton fait bêêê !\n" }
@troupeau = qw(Boeuf Boeuf Cheval Mouton Mouton); foreach $animal (@troupeau) { $animal->fait; }
Ça y est ! Maintenant tous les animaux parlent et sans utiliser de référence symbolique.
Mais regardez tout ce code commun. Toutes les routines "fait" ont une structure similaire : un opérateur "print" et une chaîne qui contient un texte identique excepté deux mots. Ce serait intéressant de pouvoir factoriser les parties communes au cas où nous déciderions plus tard de changer "fait" en "dit" par exemple.
Il y a réellement moyen de le faire mais pour cela nous devons tout d'abord en savoir un peu plus sur ce que l'opérateur flèche peut faire pour nous.
Class->method(@args)
essaie d'appeler la subroutine "Class::method" de la manière suivante :
Class::method("Class", @args);
(Si la subroutine ne peut être trouvée, l'héritage intervient mais nous le verrons plus tard.) Cela signifie que nous récupérons le nom de la classe comme premier paramètre (le seul paramètre si aucun autre argument n'est fourni). Donc nous pouvons réécrire la subroutine "fait" du "Mouton" ainsi :
sub Mouton::fait { my $class = shift; print "un $class fait bêêê !\n"; }
Et, de manière similaire, pour les deux autres animaux :
sub Boeuf::fait { my $class = shift; print "un $class fait mheuu !\n"; } sub Cheval::fait { my $class = shift; print "un $class fait hiiii !\n"; }
Dans chaque cas, $class aura la valeur appropriée pour la subroutine. Mais, encore une fois, nous avons des structures similaires. Pouvons-nous factoriser encore plus ? Oui, en appelant une autre méthode de la même classe.
{ package Boeuf; sub cri { "mheuu" } sub fait { my $class = shift; print "un $class fait ", $class->cri, " !\n" } }
Maintenant, lorsque nous appelons "Boeuf->fait", $class vaut "Boeuf" dans "cri". Cela permet de choisir la méthode "Boeuf->cri" qui retourne "mheuu". Quelle différence voit-on dans la version correspondant au "Cheval" ?
{ package Cheval; sub cri{ "hiiii" } sub fait { my $class = shift; print "un $class fait ", $class->cri, " !\n" } }
Seuls le nom du package et le cri changent. Pouvons-nous donc partager la définition de "fait" entre le Boeuf et le Cheval ? Oui, grâce à l'héritage !
{ package Animal; sub fait { my $class = shift; print "un $class fait ", $class->cri, " !\n" } }
Puis nous allons demander à chaque animal « d'hériter » de "Animal" :
{ package Boeuf; @ISA = qw(Animal); sub cri { "mheuu" } }
Remarquez l'ajout du tableau @ISA. Nous y reviendrons dans une minute.
Qu'arrive-t-il maintenant lorsque nous appelons "Boeuf->fait" ?
Tout d'abord, Perl construit la liste d'arguments. Dans ce cas, c'est juste "Boeuf". Puis Perl cherche la subroutine "Boeuf::fait". Mais elle n'existe pas alors Perl regarde le tableau d'héritage @Boeuf::ISA. Il existe et contient le seul nom "Animal".
Perl cherche alors "fait" dans "Animal", c'est à dire "Animal::fait". Comme elle existe, Perl appelle cette subroutine avec la liste d'arguments pré-calculée.
Dans la subroutine "Animal::fait", $class vaut "Boeuf" (le premier et seul argument). Donc, lorsque nous arrivons à "$class->cri", la recherche commence par "Boeuf->cri" qui est trouvé au premier essai sans passage par le tableau @ISA. Ça marche !
Si "Animal" a lui aussi un tableau @ISAi, alors il est utilisé aussi. La recherche est récursive, en profondeur d'abord et de gauche à droite dans chaque @ISA. Classiquement, chaque @ISA ne contient qu'un seul élément (des éléments multiples impliquent un héritage multiple et donc de multiples casse-tête) ce qui définit un bel arbre d'héritage.
Lorsqu'on active "use strict", on obtient un avertissement concernant @ISA puisque c'est une variable dont le nom ne contient pas explicitement un nom de package et qui n'est pas déclarée comme une variable lexicale (via « my »). On ne peut pas en faire une variable lexicale (car elle doit appartenir au package pour être accessible au mécanisme d'héritage). Voici donc plusieurs moyens de gérer cela :
Le moyen le plus simple est d'inclure explicitement le nom du package :
@Boeuf::ISA = qw(Animal);
On peut aussi créer une variable de package implicitement :
package Boeuf; use vars qw(@ISA); @ISA = qw(Animal);
Si vous préférez une méthode plus orientée objet, vous pouvez changer :
package Boeuf; use Animal; use vars qw(@ISA); @ISA = qw(Animal);
en :
package Boeuf; use base qw(Animal);
# Package Animal comme au-dessus { package Mulot; @ISA = qw(Animal); sub cri { "fiiik" } sub fait { my $class = shift; print "un $class fait ", $class->cri, " !\n"; print "[mais vous pouvez à peine l'entendre !]\n"; } }
Mulot->fait;
Le résultat sera :
un Mulot fait fiiik ! [mais vous pouvez à peine l'entendre !]
Ici, "Mulot" a sa propre routine cri, donc "Mulot->fait" n'appellera pas immédiatement "Animal->fait". On appelle cela la surcharge (« overridding » en anglais). En fait, nous n'avons pas besoin du tout de dire qu'un "Mulot" est un "Animal" puisque toutes les méthodes nécessaires à "fait" sont définies par "Mulot".
Mais maintenant nous avons dupliqué le code de "Animal->fait" et cela peut nous amener à des problèmes de maintenance. Alors, pouvons nous l'éviter ? Pouvons nous dire qu'un "Mulot" fait exactement comme un autre "Animal" mais en ajoutant un commentaire en plus ? Oui !
Tout d'abord, nous pouvons appeler directement la méthode "Animal::fait" :
# Package Animal comme au-dessus { package Mulot; @ISA = qw(Animal); sub cri { "fiiik" } sub fait { my $class = shift; Animal::fait($class); print "[mais vous pouvez à peine l'entendre !]\n"; } }
Remarquez que nous sommes obligés d'inclure le paramètre $class (qui doit certainement valoir "Mulot") comme premier paramètre de "Animal::fait" puisque nous n'utilisons plus l'opérateur flèche. Pourquoi ne plus l'utiliser ? Si nous appelons "Animal->fait" ici, le premier paramètre de la méthode sera "Animal" et non "Mulot" et lorsqu'on arrivera à l'appel de "cri", nous n'aurons pas la bonne classe.
L'invocation directe de "Animal::fait" est tout autant problématique. Que se passe-t-il si la subroutine "Animal::fait" n'existe pas et est en fait héritée d'une classe mentionnée dans @Animal::ISA ? Puisque nous n'utilisons pas l'opérateur flèche, nous n'avons pas la moindre chance que cela fonctionne.
Notez aussi que le nom de la classe "Animal" est maintenant codée explicitement pour choisir la bonne subroutine. Ce sera un problème pour celui qui changera le tableau @ISA de "Mulot" sans remarquer que "Animal" est utilisé explicitement dans "fait". Ce n'est donc pas la bonne méthode.
# Animal comme au-dessus { package Mulot; # même @ISA et même &cri qu'au-dessus sub fait { my $class = shift; $class->Animal::fait; print "[mais vous pouvez à peine l'entendre !]\n"; } }
Ça marche. En utilisant cette syntaxe, nous commençons par chercher dans "Animal" pour trouver "fait" et nous utilisons toute la chaîne d'héritage de "Animal" si on ne la trouve pas tout de suite. Et comme le premier argument sera $class, la méthode "fait" trouvée pourra éventuellement appeler "Mulot::cri".
Mais ce n'est pas la meilleure solution. Nous avons encore à coordonner le tableau @ISA et le nom du premier package de recherche. Pire, si "Mulot" a plusieurs entrées dans son tableau @ISA, nous ne savons pas nécessairement laquelle définit réellement "fait". Alors, y a-t-il une meilleure solution ?
# Animal comme au dessus { package Mulot; # même @ISA et même &cri qu'au dessus sub dir { my $class = shift; $class->SUPER::fait; print "[mais vous pouvez à peine l'entendre !]\n"; } }
Donc, "SUPER::fait" signifie qu'il faut chercher la subroutine "fait" dans les packages listés par @ISA (en commençant par le premier).
Class->method(@args);
ou son équivalent :
$a = "Class"; $a->method(@args);
qui construit la liste d'argument :
("Class", @args)
et essaye d'appeler :
Class::method("Class", @args);
Si "Class::method" n'est pas trouvée, alors le tableau @Class::ISA est utilisé (récursivement) pour trouver un package qui propose "method" puis la méthode est appelée.
En utilisant cette simple syntaxe, nous avons des méthodes de classes avec héritage (multiple), surcharge et extension. Et nous avons été capable de factoriser tout le code commun tout en fournissant un moyen propre de réutiliser l'implémentation avec des variantes. C'est ce que fournit le coeur de la programmation orientée objet mais les objets peuvent aussi fournir des données d'instances que nous n'avons pas encore vues.
{ package Animal; sub fait { my $class = shift; print "un $class fait ", $class->cri, " !\n" } } { package Cheval; @ISA = qw(Animal); sub cri { "hiiii" } }
Cela permet d'appeler "Cheval->fait" qui est en fait "Animal::fait" qui, elle-même appelle en retour "Cheval::cri" pour obtenir le cri spécifique. Ce qui produit :
un Cheval fait hiiii !
Mais tous nos objets Cheval (Chevaux ;-) doivent absolument être identiques. Si j'ajoute une subroutine, tous les chevaux la partagent automatiquement. C'est très bien pour faire des chevaux identiques mais, alors, comment faire pour distinguer les chevaux les uns des autres ? Par exemple, supposons que nous voulions donner un nom au premier cheval. Il nous faut un moyen de conserver son nom indépendamment des autres chevaux.
Nous pouvons le faire en introduisant une nouvelle notion appelée « instance ». Une « instance » est généralement créée par une classe. En Perl, n'importe quelle référence peut être une instance. Commençons donc par la plus simple des références qui peut stocker le nom d'un cheval : une référence sur un scalaire.
my $nom = "Mr. Ed"; my $parleur = \$nom;
Maintenant $parleur est une référence vers ce qui sera une donnée spécifique de l'instance (le nom). L'étape finale consiste à la transformer en une vraie instance grâce à l'opérateur appelé "bless" (bénir en anglais) :
bless $parleur, Cheval;
Cet opérateur associe le package nommé "Cheval" à ce qui est pointé par la référence. À partir de ce moment, on peut dire que $parleur est une instance de "Cheval". C'est à dire que c'est un "Cheval" spécifique. La référence en tant que telle n'est pas modifiée et on peut continuer à l'utiliser avec les opérateurs traditionnels de déréférencement.
my $bruit = $parleur->cri;
Pour appeler "cri", Perl remarque tout d'abord que $parleur est une référence bénie (via bless()) et donc une instance. Ensuite, il construit la liste des arguments qui, dans ce cas, n'est que $parleur. (Plus tard, nous verrons que les autres arguments suivent la variable d'instance exactement comme avec les classes.)
Maintenant la partie intéressante : Perl récupère la classe ayant bénie l'instance, dans notre cas "Cheval", et l'utilise pour trouver la subroutine à appeler. Dans notre cas, "Cheval::cri" est trouvée directement (sans utiliser d'héritage) et cela nous amène à l'appel finale de la subroutine :
Cheval::cri($parleur)
Remarquez que le premier paramètre est bien l'instance et non le nom de la classe comme auparavant. Nous obtenons "hiiii" comme valeur de retour et cette valeur est stockée dans la variable $bruit.
Si "Cheval::cri" n'avait pas existé, nous aurions été obligé d'explorer @Cheval::ISA pour y rechercher cette subroutine dans l'une des super-classes exactement comme avec les méthodes de classes. La seule différence entre une méthode de classe et une méthode d'instance est le premier argument qui est soit un nom de classe (une chaîne) soit une instance (une référence bénie).
{ package Cheval; @ISA = qw(Animal); sub cri { "hiiii" } sub nom { my $self = shift; $$self; } }
Maintenant, appelons cette méthode :
print $parleur->nom, " fait ", $parleur->cri, "\n";
Dans "Cheval::nom", le tableau @_ contient juste $parleur que "shift" stocke dans $self. (Il est classique de dépiler le premier paramètre dans une variable nommée $self pour les méthodes d'instance. Donc conservez cela tant que vous n'avez pas de bonnes raisons de faire autrement.) Puis, $self est déréférencé comme un scalaire pour obtenir "Mr. Ed". Le résultat sera :
Mr. Ed fait hiiii
{ package Cheval; @ISA = qw(Animal); sub cri { "hiiii" } sub nom { my $self = shift; $$self; } sub nomme { my $class = shift; my $nom = shift; bless \$nom, $class; } }
Maintenant, grâce à la méthode "nomme", nous pouvons créer un cheval :
my $parleur = Cheval->nomme("Mr. Ed");
Remarquez que nous sommes revenus à une méthode de classe donc les deux arguments de "Cheval::nomme" sont "Cheval" et "Mr. Ed". L'opérateur "bless" en plus de bénir $nom retourne une référence vers $nom qui est parfait comme valeur de retour. Et c'est comme cela qu'on construit un cheval.
Ici, nous avons appelé le constructeur "nomme" ce qui indique que l'argument de ce constructeur est le nom de ce "Cheval" particulier. Vous pouvez utiliser différents constructeurs avec différents noms pour avoir des moyens différents de « donner naissance » à un objet. En revanche, vous constaterez que de nombreuses personnes qui sont venues à Perl à partir de langages plus limités n'utilisent qu'un seul constructeur appelé "new" avec plusieurs façons d'interpréter ses arguments. Tous les styles sont corrects tant que vous documentez (et vous le ferez n'est-ce pas ?) le moyen de donner naissance à votre objet.
{ package Animal; sub fait { my $class = shift; print "un $class fait ", $class->cri, " !\n" } sub nom { my $self = shift; $$self; } sub nomme { my $class = shift; my $nom = shift; bless \$nom, $class; } } { package Cheval; @ISA = qw(Animal); sub cri { "hiiii" } }
Bon. Mais que se passe-t-il si nous appelons "fait" depuis une instance ?
my $parleur = Cheval->nomme("Mr. Ed"); $parleur->fait;
Nous obtenons le texte suivant :
un Cheval=SCALAR(0xaca42ac) fait hiiii !
Pourquoi ? Parce que la routine "Animal::fait" s'attend à recevoir un nom de classe comme premier paramètre et non une instance. Lorsqu'une instance est passée, nous nous retrouvons à utiliser un référence bénie vers un scalaire en tant que chaîne et nous obtenons ce que nous venons de voir.
sub nom { my $classouref = shift; ref $classouref ? $$classouref # c'est une instance, on retourne le nom : "un $classouref anonyme"; # c'est une classe, on retourne un nom générique }
Ici, l'opérateur "?:" devient le moyen de choisir entre déréférencement ou chaîne. Maintenant nous pouvons utiliser notre méthode indifféremment avec une classe ou avec une instance. Notez que nous avons transformé le premier paramètre en $classouref pour indiquer ce qu'il contient :
my $parleur = Cheval->nomme("Mr. Ed"); print Cheval->nom, "\n"; # affiche "un Cheval anonyme\n" print $parleur->nom, "\n"; # affiche "Mr. Ed\n"
Modifions "fait" pour utiliser "nom" :
sub fait { my $classouref = shift; print $classouref->nom, " fait ", $classouref->cri, "\n"; }
Et puisque "cri" fonctionne déjà que ce soit avec une instance ou une classe, nous avons fini !
{ package Animal; sub nomme { my $class = shift; my $nom = shift; bless \$nom, $class; } sub nom { my $classouref = shift; ref $classouref ? $$classouref # c'est une instance, on retourne le nom : "un $classouref anonyme"; # c'est une classe, on retourne un nom générique } sub fait { my $classouref = shift; print $classouref->nom, " fait ", $classouref->cri, "\n"; } sub mange { my $classouref = shift; my $nourriture = shift; print $classouref->nom, " mange $nourriture.\n"; } } { package Cheval; @ISA = qw(Animal); sub cri { "hiiii" } } { package Mouton; @ISA = qw(Animal); sub cri { "bêêê" } }
Essayons ce code :
my $parleur = Cheval->nomme("Mr. Ed"); $parleur->mange("du foin"); Mouton->mange("de l'herbe");
qui affiche :
Mr. Ed mange du foin. un Mouton anonyme mange de l'herbe.
Une méthode d'instance avec des paramètres est appelé avec, comme paramètres, l'instance puis la liste des paramètres. Donc ici, le premier appel est comme :
Animal::mange($parleur, "du foin");
Mais comment transformer notre cheval en une table de hachage ? Rappelez-vous qu'un objet est une référence bénie. Il est tout à fait possible d'utiliser une référence bénie vers une table de hachage plutôt que vers un simple scalaire à partir du moment où chaque accès au contenu de cette référence l'utilise correctement.
Créons un mouton avec un nom et une couleur :
my $mauvais = bless { Nom => "Evil", Couleur => "noir" }, Mouton;
Ainsi "$mauvais->{Nom}" donne et "Evil" et "$mauvais->{Couleur}" donne "Noir". Mais "$mauvais->nom" doit donner le nom et cela ne marche plus car cette méthode attend une référence vers un simple scalaire. Ce n'est pas très grave car c'est simple à corriger :
## dans Animal sub nom { my $classouref = shift; ref $classouref ? $classouref->{Nom} : "un $classouref anonyme"; }
Bien sûr, "nomme" construit encore un mouton avec une référence vers un scalaire. Corrigeons là aussi :
## dans Animal sub nomme { my $class = shift; my $nom = shift; my $self = { Nom => $nom, Couleur => $class->couleur_defaut }; bless $self, $class; }
D'où vient ce "couleur_defaut" ? Eh bien, puisque "nomme" ne fournit que le nom, nous devons encore définir une couleur. Nous avons donc une couleur par défaut pour la classe. Pour un mouton, nous pouvons la définir à blanc :
## dans Mouton sub couleur_defaut { "blanc" }
Et pour nous éviter de définir une couleur par défaut pour toutes les classes, nous allons définir aussi une méthode générale dans "Animal" qui servira de « couleur par défaut » par défaut :
## dans Animal sub couleur_defaut { "marron" }
Comme "nom" et "nomme" étaient les seules méthodes qui utilisaient explicitement la « structure » des objets, toutes les autres méthodes restent inchangées et donc "fait" fonctionne encore comme avant.
## dans Animal sub couleur { $_[0]->{Couleur} } sub set_couleur { $_[0]->{Couleur} = $_[1]; }
Remarquez un autre moyen d'utiliser les arguments : $_[0] est utilisé directement plutôt que via un "shift". (Cela économise un tout petit peu de temps pour quelque chose qui peut être invoqué fréquemment.) Maintenant, on peut choisir la couleur de Mr. Ed :
my $parleur = Cheval->nomme("Mr. Ed"); $parleur->set_couleur("noir-et-blanc"); print $parleur->nom, " est de couleur ", $parleur->couleur, "\n";
qui donne :
Mr. Ed est de couleur noir-et-blanc
Citons quelques modules qui sont digne d'intérêt Class::Accessor, Class::Class, Class::Contract, Class::Data::Inheritable, Class::MethodMaker et Tie::SecureHash
Portions of this text have been derived from Perl Training materials originally appearing in the Packages, References, Objects, and Modules course taught by instructors for Stonehenge Consulting Services, Inc. and used with permission.
Portions of this text have been derived from materials originally appearing in Linux Magazine and used with permission.