Objets, classes et rôles en Perl 6

Dans le modèle de programmation objet fondé sur des classes (le modèle OO de base de Perl 6), un objet est plus particulièrement l'instance d'une classe, dans laquelle l'objet peut être une combinaison de propriétés : variables, fonctions ou méthodes et structures de données. La classe définit la partie de ces propriétés commune à tous les objets de la classe (méthodes, contraintes), alors que l'objet contient celles de ces propriétés (identifiant, attributs, etc.) qui sont propres à l'objet et définissent son état.

Dans ce modèle de programmation, il convient donc en principe de définir d'abord une classe à laquelle appartient l'objet. La classe définit les propriétés et le comportement de l'objet. C'est seulement ensuite que l'on pourra définir des objets instanciant ladite classe et possédant leurs caractéristiques propres.

Une classe définit généralement surtout des attributs (qui décriront l'état de l'objet) et des méthodes (le comportement de l'objet), qui sont des fonctions associées à une classe et s'appliquant aux objets appartenant à cette classe.

Sans trop nous préoccuper des détails de syntaxe pour l'instant, nous pourrions définir une classe PointDuPlan :

class PointDuPlan {
    has $.abscisse;    # x
    has $.ordonnée;    # y
    
    method coordonnées {        # accesseur
        return (self.abscisse, self.ordonnée)
    }
    
    method distanceAuCentre {
        (self.abscisse ** 2 + self.ordonnée ** 2) ** 0.5
    }
    method coordonnéesPolaires {
        my $rayon = self.distanceAuCentre;
        my $thêta = atan2 self.ordonnée, self.abscisse; # (azimut)
        return $rayon, $thêta;
    }
}

Le mot-clef class permet de déclarer une classe ; dans l'exemple ci-dessus, la classe est définie dans le bloc de code qui suit la déclaration. Cette définition de la classe dit qu'un objet de type PointDuPlan possédera deux attributs (par défaut en lecture seule), son abscisse et son ordonnée. La classe PointDuPlan fournit en outre trois méthodes : coordonnées (simple accesseur aux coordonnées cartésiennes du point), distanceAuCentre, et coordonnéesPolaires.

Dans la définition d'une méthode, self est une référence à l'objet invoquant la méthode (comme this ou me dans d'autres langages) ; il est également possible d'utiliser $, si bien que $.abscisse et self.abscisse sont à peu près équivalents et renvoient l'abscisse de l'objet invoquant la méthode.

Ici, on aurait pu aussi écrire self!abscisse au lieu de self.abscisse (avec un point d'exclamation au lieu d'un simple point) pour accéder à l'abscisse de l'objet invoquant. Ces deux syntaxes ne veulent cependant pas dire tout à fait la même chose : la première, avec l'opérateur « . », est un véritable appel de méthode, alors que la seconde, avec l'opérateur « ! », est un accès direct à la propriété de l'objet ; cette seconde syntaxe n'est donc disponible qu'à l'intérieur même de la classe définissant l'objet (et sera éventuellement un peu plus rapide), alors que la première peut être appelée depuis l'extérieur de la classe. Nous reviendrons sur cette distinction.

À partir de cette classe, il est possible d'instancier un objet comme suit :

my $point = PointDuPlan.new(
    abscisse => 3,
    ordonnée => 4,
    );

say $point.WHAT;
say "Coordonnées : ", $point.coordonnées;
say "Distance au point origine : ", $point.distanceAuCentre.round(0.01);
printf "%s: rayon = %.4f, thêta (rad) = %.4f\n", 
    "Coordonnées polaires", $point.coordonnéesPolaires;

# Imprime :
# (Point2D)
# Coordonnées : (3 4)
# Distance au point origine : 5
# Coordonnées polaires: rayon = 5.0000, thêta (rad) = 0.9273

L'objet $point est instancié (c'est-à-dire créé) par l'invocation de méthode $PointDuPlan.new, en lui passant les paramètres nommés abscisse et ordonnée afin d'initialiser les attributs correspondants de l'objet. Cette méthode n'est pas définie explicitement dans notre classe : il n'y a pas besoin de le faire parce que Perl 6 fournit le constructeur .new par défaut (on verra plus loin par quel mécanisme). Mais rien n'oblige à utiliser ce constructeur, il est possible de créer son propre constructeur ; nous verrons plus loin que cela conduit à gérer des concepts de plus bas niveau ; tenons-nous-en pour l'instant au constructeur par défaut.

Les attributs $.abscisse et $.ordonnée de la classe $PointDuPlan sont par défaut en lecture seule (non mutables). Après tout, quand on définit un point du plan, il est souvent fixe et il n'y a généralement plus de raison de modifier ses coordonnées ensuite.

Supposons cependant que notre application traite de cinématique ou soit à la base d'un jeu vidéo : dans ce cas, on désire sans doute que certains points ou ensembles de points puissent se déplacer. Nous allons avoir besoin d'une nouvelle classe autorisant la modification des coordonnées : PointMobile.

Faut-il redéfinir toutes les méthodes pour une nouvelle classe ? Non, c'est inutile : nous pouvons définir une nouvelle classe héritant des propriétés de notre classe de base et y modifier ce qui ne nous convient plus ou ajouter nos besoins supplémentaires :

class PointMobile is PointDuPlan {
    has $.abscisse is rw;
    has $.ordonnée is rw;
    
    method déplace (Numeric $x, Numeric $y) {
        $.abscisse += $x;
        $.ordonnée += $y;
    }
}

La nouvelle classe PointMobile hérite de la classe PointDuPlan grâce à l'opérateur is (par l'instruction : PointMobile is PointDuPlan), c'est-à-dire qu'elle hérite de toutes ses propriétés d'origine, sauf celles qui sont explicitement modifiées ou redéfinies dans la nouvelle classe. On dit que PointMobile est une classe fille ou classe enfant (ou sous-classe) de PointDuPlan, qui est donc la classe mère ou classe parente (parfois également appelée superclasse ou surclasse).

Ici, les attributs $.abscisse et $.ordonnée sont redéfinis comme étant en lecture et en écriture (utilisation du trait is rw), c'est-à-dire qu'ils sont maintenant modifiables. De plus, une nouvelle méthode déplace est définie pour mouvoir le point invoquant en ajoutant les valeurs reçues en paramètres aux coordonnées du point. Les autres méthodes de la classe mère sont inchangées et pourront être invoquées comme précédemment. Ainsi, nous pouvons créer un nouveau point de type PointMobile, afficher ses caractéristiques, puis le déplacer et afficher ses nouvelles caractéristiques :

my $point = PointMobile.new(
    abscisse => 3,
    ordonnée => 4,
    );

say "Coordonnées : ", $point.coordonnées;
say "Distance au point origine : ", $point.distanceAuCentre.round(0.01);
printf "%s: rayon = %.4f, thêta (rad) = %.4f\n", 
    "Coordonnées polaires", $point.coordonnéesPolaires;

say "--> Déplacement du point.";
$point.déplace(4, 5);
say "Nouvelles coordonnées : ", $point.coordonnées;
say "Distance au point origine : ", $point.distanceAuCentre.round(0.01);
printf "%s: rayon = %.4f, thêta (rad) = %.4f\n", 
    "Coordonnées polaires", $point.coordonnéesPolaires;

Ce qui imprime :

Coordonnées : (3 4)
Distance au point origine : 5
Coordonnées polaires: rayon = 5.0000, thêta (rad) = 0.9273
--> Déplacement du point.
Nouvelles coordonnées : (7 9)
Distance au point origine : 11.4
Coordonnées polaires: rayon = 11.4018, thêta (rad) = 0.9098

Ici, quand le code utilisateur appelle les méthodes coordonnées, distanceAuCentre et coordonnéesPolaires, celles-ci n'existent pas dans la classe pointMobile. Mais comme cette classe hérite de PointDuPlan, le programme recherche des méthodes ayant le même nom dans la classe mère et les invoque s'il les trouve. S'il ne les trouve toujours pas dans la classe mère, il pourra être amené à remonter à la classe mère de la classe mère, et ainsi de suite dans la hiérarchie d'héritage le cas échéant.

Dans l'exemple ci-dessus, les deux attributs de la classe mère sont redéfinis dans la classe fille. Si l'on suppose pour un instant que, pour les besoins de notre application, seule l'ordonnée est susceptible de varier, alors la classe fille n'aurait besoin de redéfinir que l'ordonnée :

class PointMobile is PointDuPlan {
    has $.ordonnée is rw;
    
    method déplace (Numeric $y) {
        $.ordonnée += $y;
    }
}

Dans ce cas, la syntaxe pour créer le nouveau point doit indiquer que l'un des attributs est défini dans la classe mère (PointDuPlan) et l'autre dans la classe fille (PointMobile) :

my $point = PointMobile.new(
    PointDuPlan { abscisse => 3},
    ordonnée => 4,
);

Rien de bien compliqué à la vérité, mais si cette syntaxe paraît obscure ou peu pratique, il y a toujours la possibilité de définir son propre constructeur sur mesure.

La classe PointDuPlan est très générale et peut servir à faire de la géométrie, du dessin vectoriel, de l'animation ou toutes autres sortes de choses. On peut par exemple vouloir l'utiliser pour afficher des données à l'écran et définir à cette fin une nouvelle classe fille Pixel qui ajoute de nouvelles propriétés (couleur, peut-être transparence, etc.) à un point du plan. Selon les normes les plus communément employées, une couleur sera définie par trois nombres entiers (en fait trois octets, des entiers compris entre 0 et 255 en notation décimale) représentant les composantes rouge, verte et bleue (RVB) du pixel :

class Pixel is PointDuPlan {
    has %.couleur is rw;

    method change_couleur(%teinte) {
        self.couleur = %teinte
    }
    method change_couleur2(Int $red, Int $green, Int $blue) {
        # la signature utilise des arguments positionnels
        self.couleur = (rouge => $red, vert => $green, bleu => $blue)
    }
}

Nous avons écrit ici deux méthodes de changement des couleurs uniquement pour illustrer deux syntaxes différentes. La seconde utilise des arguments positionnels, ce qui oblige l'utilisateur à se souvenir de l'ordre (RVB) dans lequel les arguments doivent être passés ; cela peut être source de confusion et devrait probablement être évité dès que le nombre de paramètres dépasse un certain seuil (que nous laisserons à l'appréciation du lecteur). D'un autre côté, la syntaxe de la seconde méthode présente l'avantage de vérifier que les arguments reçus sont bien des entiers.

Ceci n'est qu'un exemple simplifié pour un tutoriel ; dans la réalité, on pourrait sans doute vouloir, pour garantir la robustesse du logiciel, définir un type Octet (ou un sous-ensemble du type Int), un entier compris entre 0 et 255, et s'assurer que les trois composantes RVB sont conformes à ce type (et générer une exception si ce n'est pas le cas) :

subset Octet of Int where {$_ ≥ 0 and $_ ≤ 255};

Utiliser la nouvelle classe Pixel ne pose pas de difficulté :

my $pix = Pixel.new(
    :abscisse(3),
    :ordonnée(4),
    couleur => {rouge => 34, vert => 233, bleu => 145}, 
    );

say "Le pixel d'origine a les couleurs suivantes : ", $pix.couleur.perl;

$pix.change_couleur({:rouge(195), :vert(110), :bleu(70),});
say "Le pixel modifié a les couleurs suivantes : {$pix.couleur.perl} ";
printf "Nouvelles caractéristiques du pixel : \n\tAbscisse: %d\n\tOrdonnée: %d\n\tCouleur: R: %d, V: %d, B: %d\n",
       $pix.abscisse, $pix.ordonnée, $pix.couleur<rouge>, $pix.couleur{"vert"}, $pix.couleur{"bleu"};;

$pix.change_couleur2(90, 180, 30);  # args positionnels moins clairs
say "Nouvelles couleurs :  
    R: {$pix.couleur<rouge>}, V: {$pix.couleur<vert>}, B: {$pix.couleur<bleu>} ";

La notation :abscisse(3) employée ici est simplement une autre façon de passer un argument nommé à la fonction new et est équivalente à abscisse => 3 utilisée précédemment.

Ce programme affiche :

Le pixel d'origine a les couleurs suivantes : {:bleu(145), :rouge(34), :vert(233)}
Le pixel modifié a les couleurs suivantes : {:bleu(70), :rouge(195), :vert(110)}
Nouvelles caractéristiques du pixel :
        Abcisse: 3
        Ordonnée: 4
        Couleur: R: 195, V: 110, B: 70
Nouvelles couleurs :
    R: 90, V: 180, B: 30

En programmation objet, l'utilisation du mécanisme d'héritage permet traditionnellement la réutilisation du code, c'est même sans doute la façon le plus courante d'envisager la réutilisation du code en POO, au point que l'héritage est probablement la caractéristique la plus emblématique de la POO.

Une classe peut avoir plusieurs classes parentes et, donc, hériter de plusieurs autres classes. On se retrouve alors dans une situation d'héritage multiple (voir aussi § 4.1.9). Nous pourrions par exemple vouloir construire une nouvelle classe PixelMobile, héritant à la fois de PointMobile et de Pixel. C'est techniquement tout à fait faisable en Perl 6, et même théoriquement assez simple à faire :

class PixelMobile is PointMobile is Pixel {
    # ...
}

mais ce genre de démarche pose assez vite de réelles difficultés de mise en œuvre : s'il y a conflit (par exemple collision de nommage entre deux méthodes) entre les deux classes mères, laquelle l'emporte ? On peut également rencontrer des problèmes d'héritage à répétition si les deux classes mères héritent de la même classe « grand-mère » (ou « aïeule ») : quelle copie de la classe « grand-mère » ou ancêtre commune doit-on conserver ? Il existe des mécanismes pour gérer ce genre de situation (par exemple en C++), mais on peut vite arriver à de gros problèmes de conception et à des bogues particulièrement difficiles à résoudre.

L'héritage multiple était à l'origine un concept intellectuellement fort séduisant, mais on s'est aperçu à l'usage qu'il peut vite devenir complexe à maîtriser, car il crée de multiples dépendances souvent implicites et difficiles à démêler. C'est pourquoi de nombreux langages orientés objet relativement récents, comme Java (sorti en 1995, tout de même), ont préféré renoncer purement et simplement au paradigme de l'héritage multiple.

Perl 6 supporte le mécanisme d'héritage multiple si vous y tenez, et vous pouvez donc y aller à cœur joie si vous aimez prendre le risque de vous tirer une balle dans le pied. À notre humble avis, ce mécanisme fonctionne plutôt assez bien dans des cas simples, bien compris et bien conçus, et il n'y a donc pas forcément lieu de l'excommunier aveuglément dans ce genre de situations bien claires, mais il devient assez vite indéchiffrable quand l'arborescence des héritages s'étoffe ou se complique notablement.

L'auteur de ces lignes a eu l'occasion de travailler assez intensément sur le noyau d'un système d'exploitation presque entièrement écrit en C++ (l'autre langage utilisé étant de l'assembleur) avec utilisation abondante d'héritage multiple et peut témoigner du fait que l'on se retrouve parfois avec du code « write-only » (en écriture seule), c'est-à-dire du code que l'on maîtrise (ou croit maîtriser) au moment où on l'écrit, mais assez incompréhensible quand on le relit ou le maintient quelques semaines ou mois plus tard. Nous verrons plus loin que Perl 6 fournit un autre mécanisme fondamental de réutilisation du code, les rôles, considéré comme plus expressif et plus fiable quand les choses deviennent complexes. Les rôles permettent d'éviter l'héritage multiple et éliminent ainsi une bonne partie de ses pièges.

La composition et la délégation sont d'autres moyens classiques de structuration et de réutilisation de code.

Considérons un chien. Un chien est un mammifère et hérite de certaines caractéristiques des mammifères, comme la présence de mamelles destinées à l'allaitement des petits, qui sont propres aux mammifères, et la colonne vertébrale, que les mammifères héritent des vertébrés (de même que les poissons, les oiseaux, les reptiles, etc.). Jusqu'ici, la hiérarchie des classes paraît simple et naturelle.

Mais les chiens peuvent avoir des caractéristiques ou comportements très variés : chien de compagnie, chien berger, chien de chasse, chien de traîneau, chien guide d'aveugle, chien policier dressé à flairer des stupéfiants ou des explosifs, chien d'avalanche, chien errant ou même peut-être chien marron ou féral (animal domestique retourné à la vie sauvage ou descendant d'individus retournés à la vie sauvage). Ce sont des comportements additionnels qui peuvent être ajoutés au chien. Un mammifère comme le chat domestique peut aussi être un animal de compagnie ou être féral (on parle alors de chat haret, qui est un individu de l'espèce chat domestique se trouvant à l'état sauvage, à distinguer des chats sauvages, qui désignent habituellement des espèces différentes du chat domestique) ; de même, un mustang est un cheval nord-américain revenu à l'état sauvage ou descendant de spécimens revenus à l'état sauvage ; mais un mustang peut aussi être capturé, dressé et ramené à l'état domestique. Ce retour à l'état sauvage et inversement à l'état domestique ne concerne pas que les mammifères : les pigeons de nos villes proviennent souvent des anciennes populations de pigeons voyageurs autrefois bien plus utilisés que de nos jours. Cela peut même concerner des invertébrés (comme les essaims d'abeilles mellifères). On voit facilement que la modélisation hiérarchique des chaînes d'héritage ne fonctionne pas bien pour décrire ce genre de comportements.

On pourra définir des classes Chien, Chat, Cheval, etc., héritant de la classe Mammifère (héritant elle-même de la classe Vertébré), et des rôles pour les chiens bergers ou ceux retournés à l'état sauvage, puis, éventuellement, définir des sous-classes de Chien, Chat ou Cheval à l'aide de ces rôles :

class Mammifère is Vertébré  { ... }
class Oiseau    is Vertébré  { method vole   {...} }
class Chien     is Mammifère { method aboie  {...} }
class Cheval    is Mammifère { method hennit {...} }
class Chat      is Mammifère { method miaule {...} }

role Animal-de-compagnie { ... }
role Chien-berger        { ... }
role Féral               { ... }    # animal retourné à l'état sauvage
role Guide               { ... }    # guide d'aveugle

class Chien-guide        is Chien  does Guide { ... }
class Chien-de-compagnie is Chien  does Animal-de-compagnie { ... }
class Chien-errant       is Chien  does Féral { ... }
class Chat-de-compagnie  is Chat   does Animal-de-compagnie { ... }
class Mustang            is Cheval does Féral { ... }
class Chat-haret         is Chat   does Féral { ... } 
                                    # distinct du chat sauvage
class Canari             is Oiseau does Animal-de-compagnie { ... }

Un rôle est ajouté à une classe ou à un objet à l'aide du mot-clef does (par opposition au mot is utilisé pour l'héritage). Ces mots-clefs distincts reflètent la signification différente de ces caractéristiques : la composition de rôle donne à une classe le comportement associé au rôle, mais cela ne signifie pas que l'objet attributaire de ce rôle soit la même chose que ce rôle.

Si les rôles Animal-de-compagnie et Féral avaient été définis comme des classes, alors les classes Chien-de-compagnie et Chien-Errant auraient chacune hérité en direct de deux classes en parallèle, avec les risques déjà mentionnés associés à l'héritage multiple. La composition d'un rôle à une classe permet d'éviter de construire un arbre d'héritage multiple qui est en fait peu justifié et peut vite devenir touffu et difficile à maintenir. L'utilisation judicieuse des classes et des rôles permet de mettre en place une modélisation plus simple, plus naturelle et plus conforme aux rapports réels entre les différents types d'entités ou de comportements à modéliser, et dès lors certainement plus facile à comprendre et à maintenir.

En outre, la composition de rôles multiples ayant les mêmes noms de méthodes génère immédiatement des conflits au lieu de se résoudre silencieusement à l'une d'entre elles, comme c'est le cas avec l'héritage multiple. Dans ce cas, les conflits sont identifiés dès la compilation (et non à l'exécution), ce qui a le mérite d'empêcher dès le départ qu'un bogue sournois passe inaperçu.

Tandis que les classes ont pour principal objectif la définition et la conformité des types, les rôles sont en Perl 6 surtout un moyen de réutiliser du code.

role Dessinable {
    has $.couleur is rw;
    method dessiner { ... }
}
class Forme {
    method aire { ... }
}

class Rectangle is Forme does Dessinable {
    has $.largeur;
    has $.hauteur;
    method aire {
        $!largeur * $!hauteur;
   }
    method dessiner() {
        for 1..$.hauteur {
            say 'x' x $.largeur;
        }
    }
}

Rectangle.new(largeur => 8, hauteur => 3).dessiner;

Ce qui affiche le rectangle ASCII :

~ perl6 test_rectangle.pl
xxxxxxxx
xxxxxxxx
xxxxxxxx

Un rôle peut ajouter un comportement à une classe entière ou à un seul objet d'une classe :

class Chien-guide is Chien does Guide { 
    ... 
} # Composition d'un rôle dans une classe


my $chien = Chien.new;
$chien does Guide;   # Composition d'un rôle dans un objet individuel

Bien que les rôles soient distincts des classes, tous deux sont ou définissent des types. Un rôle peut donc apparaître dans une déclaration de variable là où l'on mettrait habituellement une classe. Par exemple, un rôle Aveugle pour un Humain pourrait comprendre un attribut de type Guide ; cet attribut pourrait contenir un chien guide, un cheval guide, un guide humain ou même un robot guide :

class Humain {
     has Chien $chien;      # Peut contenir un type quelconque de
     ...                    # chien, ayant un rôle de guide ou non
}
 role Aveugle {
     has Guide $guide;      # Peut contenir tout objet ayant le rôle 
     ...                    # de guide, qu'il s'agisse d'un chien
                            # ou d'autre chose
}

Un certain nombre des types internes de Perl sont définis par des rôles et non des classes, comme IO, Iterable, Iterator, Numeric, Rational, Real, etc. À titre d'exemple, le schéma suivant des relations de types des types Rat et Rational représente en noir les types définis par des classes et en bleu les types définis par des rôles :

En POO, l'encapsulation est l'idée de protéger du monde extérieur les données contenues dans un objet et de n'offrir à l'utilisateur d'une classe que des méthodes d'accès à ces objets. Ces méthodes sont parfois appelées des accesseurs (ou getters) et mutateurs (ou setters). Cela permet notamment d'assurer que les propriétés de l'objet seront validées par les méthodes de l'objet et ne seront plus de la seule responsabilité de l'utilisateur extérieur. Ce dernier ne pourra pas modifier directement l'information et risquer de mettre en péril les axiomes et les propriétés comportementales de l'objet.

L'encapsulation est une forme forte d'abstraction des données et d'abstraction procédurale. Certains langages objet comme Eiffel vont même plus loin : plutôt que de parler d'invocation de méthodes, ils préfèrent envisager une sémantique de passage de messages : l'utilisateur envoie un message à l'objet et l'objet exécute l'action demandée dans le message (et il renvoie éventuellement un message de retour). L'utilisateur d'un objet ne connaît que l'interface de définition des messages (nom de l'action à invoquer et paramètres en entrée et en sortie). Dans la pratique, la différence entre l'envoi d'un message et l'invocation d'une méthode est généralement très ténue et tient surtout d'une différence de vocabulaire : la sémantique réelle de fonctionnement est ou du moins peut être en définitive pratiquement la même.

L'objet est ainsi vu de l'extérieur comme une boîte noire ayant certaines propriétés et ayant un comportement spécifié. La manière dont ces propriétés ont été implémentées est alors en principe cachée aux utilisateurs de la classe. Elle est cachée non pas dans le sens qu'il ne peut pas la connaître (au moins dans le monde de l'open source, il a accès à cette connaissance), mais dans le sens qu'il ne peut pas tirer parti de cette connaissance pour passer outre l'interface qui lui est fournie. On peut changer cette implémentation de la classe sans changer le comportement extérieur de l'objet. Cela permet donc de séparer la spécification du comportement d'un objet, de l'implémentation pratique de ces spécifications.

Les principes de l'encapsulation sont appliqués de façons très diverses selon les langages. Certains, comme Eiffel ou Smalltalk, autorisent généralement l'accès en lecture depuis le programme appelant, mais ne permettent un accès en écriture que depuis la classe de l'objet. D'autres, comme C++, Java ou Ruby, ne font pas réellement de distinction selon que l'accès se fait en lecture ou en écriture, mais plutôt selon le niveau de visibilité spécifié pour l'attribut : public ou privé (et éventuellement un niveau intermédiaire, protégé, c'est-à-dire accessible aux classes dérivées ou éventuellement « amies »).

De plus, certains langages sont très stricts et interdisent complètement l'accès aux données privées, alors que d'autres (comme Perl 5 dans sa version POO d'origine) sont plus libéraux et se contentent de déconseiller l'accès direct aux données privées en comptant sur le « savoir-vivre » de l'utilisateur, mais laissent néanmoins la possibilité technique d'enfreindre le caractère privé des données ; c'est souvent une mauvaise idée (ouvrir le boîtier de l'appareil peut invalider la garantie), mais cela peut s'avérer très utile dans certains cas particuliers (il n'est peut-être pas souhaitable qu'une camisole de force vous empêche de travailler). À noter que, même si ce n'est pas sa philosophie dominante, Perl 5 offre tout de même des moyens d'assurer une encapsulation stricte si on le désire, mais ce n'est pas le sujet.

L'encapsulation ne concerne pas seulement les attributs d'un objet, il est également éventuellement possible, selon les langages, de définir des méthodes privées (qui ne peuvent être appelées que depuis la classe de l'objet) et des méthodes publiques accessibles depuis l'extérieur.

Perl 6 vous laisse entièrement libre de choisir le modèle d'encapsulation que vous désirez appliquer à vos objets (et leurs attributs et méthodes).

Par défaut, tous les attributs d'un objet Perl 6 sont privés. Si vous déclarez une classe comme suit :

class Point2D {
    has $!x;
    has $!y;
    # …
    method valeur_x { return $!x }
    method valeur_y { return $!y }
}

les coordonnées $!x et $!y sont entièrement privées et ne sont accessibles que depuis l'intérieur de la classe. C'est pourquoi nous avons ajouté dans l'exemple de la classe des accesseurs (méthodes permettant de lire le contenu des coordonnées). Ces attributs sont de plus non modifiables (lecture seule).

Mais, comme nous l'avons vu précédemment, si vous déclarez cette classe comme suit :

class Point2D {
    has $.x;
    has $.y;
    # ...
}

les coordonnées restent en principe privées, mais Perl 6 génère automatiquement des méthodes nommées $nom-objet.x et $nom-objet.y permettant en fait d'y accéder depuis l'extérieur de la classe (le programme appelant ou une autre classe) comme si elles étaient publiques.

class Point2D {
    has $.x;
    has $.y;
    # ...
}
my $point = Point2D.new(x => 2, y => 3);
say $point.x;       # -> 2

L'accès en lecture seule ou en lecture et écriture est géré séparément par le trait is rw (voir § 2.2). En cas de besoin, il est toujours possible de mettre un attribut en lecture et écriture tout en le gardant privé, et d'ajouter explicitement des méthodes permettant un accès dans le mode voulu. En bref, Perl 6 propose un mode d'accès par défaut, mais vous laisse décider finement de ce que vous désirez autoriser.

Notons au passage que certains spécialistes de la programmation orientée objet considèrent que les accesseurs (même en simple lecture) sont une mauvaise chose et contreviennent aux principes de l'encapsulation. C'est vrai si l'accesseur est considéré comme une possibilité d'accès aux attributs internes d'un objet, ça l'est moins si l'on considère qu'il n'est qu'une méthode parmi d'autres ayant pour but que de renvoyer une propriété de l'objet, laquelle peut être aussi bien la valeur d'un attribut défini dans la structure de l'objet, qu'une valeur calculée à partir de plusieurs des caractéristiques internes de l'objet. Après tout, même si la classe Point2D décrite ci-dessus change d'implémentation et définit désormais en interne les points par des coordonnées polaires, rien n'empêche pour autant à cette classe de continuer à fournir dans son interface une méthode .x calculant l'abscisse du point à partir des coordonnées polaires. Bref, l'objection des puristes de la programmation orientée objet ne nous convainc qu'à moitié. Surtout, Perl 6 vous offre la possibilité d'accéder aux propriétés de l'objet si vous le désirez, ou de vous interdire de la faire si vous préférez. C'est vous qui décidez.

Construire des objets avec des attributs privés pose cependant une petite difficulté. Considérons l'exemple de programme suivant :

class Point3D {
    has $.x;
    has $.y;
    has $!z;
    
    method get {
        return ($!x, $!y, $!z);
    }
};

my $a = Point3D.new(x => 23, y => 42, z => 2);
say $_ for $a.get;

Pour les besoins de cette démonstration, les coordonnées $.x et $.y sont déclarées « publiques », mais la hauteur $!z est privée. À l'exécution, ce programme affiche le résultat suivant :

23
42
(Any)

Que se passe-t-il ? Il apparaîtrait que la méthode get ne parvient pas à lire la hauteur, puisque celle-ci reste indéfinie. Pourtant cette méthode est bien définie à l'intérieur de la classe, elle devrait y accéder sans problème. En fait, ce n'est pas la méthode get qui est fautive, c'est la hauteur $!z qui n'est pas définie dans l'objet $a, parce qu'elle n'est pas initialisée lors de la construction de l'objet.

Le fautif est le constructeur implicite new, qui n'initialise que les attributs « publics ». Ici, la solution la plus simple consiste à ajouter une subméthode (cf. § 4.1.8) BUILD :

class Point3D {
    has $.x;
    has $.y;
    has $!z;
    
    # syntaxe permettant d'initialiser les variables privées
    submethod BUILD(:$!x, :$!y, :$!z) {
        say "Initialisation!";
    }
    method get {
        return ($!x, $!y, $!z);
    }
};

my $a = Point3D.new(x => 23, y => 42, z => 2);
say $_ for $a.get;

Cette fois, cela fonctionne comme désiré et affiche bien les trois attributs :

Initialisation!
23
42
2

Cela fonctionne parce que le constructeur par défaut new appelle la subméthode BUILD, elle-même définie par défaut. En redéfinissant cette subméthode dans notre classe, on oblige en quelque sorte new à prendre en compte l'attribut privé qui était sinon délaissé. Nous reviendrons plus loin sur le processus de construction d'un objet et la réalisation de constructeurs sur mesure.

Les méthodes sont le mode d'accès normal aux objets, que ce soit en lecture ou en écriture. Elles constituent souvent ce que l'on appelle l'interface d'une classe, c'est-à-dire la partie de la classe rendue publique et mise à la disposition des programmeurs désireux de l'utiliser. Il est donc logique et naturel que les méthodes d'une classe soient par défaut publiques, c'est-à-dire qu'elles soient accessibles depuis l'extérieur (que ce soit dans un programme utilisateur ou dans une autre classe).

Mais une classe peut aussi contenir de nombreuses méthodes faisant partie de la « cuisine interne » de la classe et qui ne sont pas destinées à être utilisées depuis l'extérieur. C'est le cas par exemple des méthodes qui dépendent de l'implémentation interne de la classe, mais n'ont pas à figurer dans l'interface offerte aux utilisateurs.

En Perl 6, une méthode privée est déclarée avec le préfixe point d'exclamation (« ! ») :

method !action-privée($x, $y) {
    ...
}

Les méthodes privées sont réellement internes à une classe et ne sont en particulier pas héritées dans les classes filles.

Tom Christiansen, l'un des principaux créateurs de Perl aux côtés de Larry Wall, a écrit qu'« un objet n'est rien de plus qu'une manière de cacher des comportements complexes derrière un petit ensemble clair et simple à utiliser ». Si tel est le cas, alors l'encapsulation est un élément absolument essentiel de la POO, et les méthodes privées sont un élément essentiel de cette encapsulation.

Il était une fois un éleveur qui avait un troupeau de moutons. Sa journée de travail ressemblait typiquement à ceci :

$éleveur.emmène_troupeau($prairie);
$éleveur.surveille_troupeau();
$éleveur.ramène_troupeau($bergerie);

Au bout d'un certain temps, grâce à son travail et à ses bonnes ventes de laine et de lait de brebis, il a étendu ses activités agricoles, et sa journée de travail s'est transformée :

$éleveur.emmène_troupeau($prairie);
$éleveur.surveille_troupeau();
$éleveur.ramène_troupeau($bergerie);
$éleveur.autre_travail_important();

Mais cet autre travail important s'avérant plutôt rentable (la demande de bon fromage de brebis bio ne cessant d'augmenter), il voulait y consacrer plus de temps. Il décida donc d'embaucher un jeune garçon comme pâtre pour s'occuper du troupeau. Désormais, la journée de travail était la suivante :

$pâtre.emmène_troupeau($prairie);
$pâtre.surveille_troupeau();
$pâtre.ramène_troupeau($bergerie);
$éleveur.autre_travail_important();

Ceci laissait au fermier plus de temps pour l'activité autre_travail_important(). Malheureusement, le jeune pâtre n'était pas bien sérieux et avait une fâcheuse tendance à crier au loup. Aussi l'éleveur décida-t-il de remplacer le pâtre par un chien berger :

$chien-berger.emmène_troupeau($prairie);
$chien-berger.surveille_troupeau();
$chien-berger.ramène_troupeau($bergerie);
$éleveur.autre_travail_important();

Le chien berger était plus fiable que le jeune pâtre et coûtait moins cher à l'éleveur, ce n'était donc que bénéfice pour celui-ci.

2-9-2-1. Délégation▲

2-9-2-2. Encapsulation▲

$chien-berger.surveille_troupeau();

$chien-berger.cerveau.tâche.surveille_troupeau;

2-9-2-3. Polymorphisme▲

Un numéro de téléphone, de compte bancaire ou de client est classiquement représenté par une chaîne de caractères ne contenant que des chiffres et éventuellement des espaces de séparation pour faciliter la lecture.

Pour permettre une validation automatique de ce type de chaîne de caractères, nous allons commencer par définir un sous-type, sous la forme d'un sous-ensemble du type chaîne de caractères :

subset NumString of Str where /^<[\d\s]>+$/;

Lorsque nous utiliserons le type NumString, Perl vérifiera pour nous que l'attribut considéré est bien une chaîne de caractères qui ne contient que des chiffres et des espaces :

my NumString $valide = "7865 998 432";  # OK
my NumString $invalide = "65b";         # KO

La première initialisation est conforme au sous-type que nous avons défini et se passe bien. La seconde ne fonctionne pas parce la chaîne "65b" contient la lettre « b » et n'est donc pas conforme à la définition du sous-type. Perl nous avertit de cette erreur :

Type check failed in assignment to $invalide; expected NumString but got Str ("65b")
  in block <unit> at compte_bancaire.pl6 line 6

À titre d'exercice, essayez d'utiliser le sous-type NumString, avec d'autres chaînes de caractères ou avec des types qui ne soient pas des chaînes. Par exemple, si vous essayez avec un nombre entier (donc de type Int), vous devriez avoir l'erreur suivante :

Type check failed in assignment to $invalide2; expected NumString but got Int (42)
  in block <unit> at compte_bancaire.pl6 line 7

Nous avons déjà vu une classe Adresse à la section 2.4 de ce tutoriel. Celle que nous allons définir ici ne sera pas très différente, mais juste un peu enrichie.

class Adresse {
    has Str $.numéro where /^\d+ \s* [bis|ter]?$/;
    has Str $.voie;
    has Str $.commune;
    has NumString $.code-postal ;

    method sérialise {
        "\t$!numéro $!voie\n" ~ 
        "\t$!code-postal $!commune";
    }
}

Nous vérifions que l'attribut numéro ne contient que des chiffres, éventuellement suivis d'espace(s) et éventuellement suivis des chaînes « bis » ou « ter », et que l'attribut code-postal est conforme au sous-type NumString défini précédemment.

Les attributs d'un objet Adresse ne sont pas mutables, car il est peu probable de devoir changer les détails d'une adresse : si une personne déménage, c'est l'ensemble de l'adresse que l'on remplacera.

La méthode sérialise renvoie l'adresse sous une forme imprimable (chaîne de caractères formatée). Nous reviendrons un peu plus loin sur la question de l'affichage de nos objets.

3-1-2-1. Créer une adresse▲

my $adresse1 = Adresse.new( numéro => "24 bis",
                            voie => "rue des Fours à pain",
                            code-postal => "69007",
                            commune => "Lyon"
                          );
say "Adresse 1 :\n", $adresse1.sérialise;

Adresse 1 :
        24 bis rue des Fours à pain
        69007 Lyon

3-1-2-2. Cloner une adresse▲

my $adresse2 = $adresse1.clone(numéro => "42", voie => "rue Pasteur");
say "Adresse 2 :\n", $adresse2.sérialise;

Adresse 2 :
        42 rue Pasteur
        69007 Lyon

3-1-2-3. Créer un tableau d'adresses▲

my $nouvelle-rue = "rue Jean d'Ormesson";
my $cp = "13003";
my $ville = "Marseille";
my @nouv_adresses;
@nouv_adresses[$_] = Adresse.new( numéro => "$_",
                                 voie => $nouvelle-rue,
                                 code-postal => $cp,
                                 commune => $ville,
                               )
                               for 1..10;

for 1..4 -> $num { 
    say "Adresse n° $num\n", @nouv_adresses[$num].sérialise;
}

Adresse n° 1
        1 rue Jean d'Ormesson
        13003 Marseille
Adresse n° 2
        2 rue Jean d'Ormesson
        13003 Marseille
Adresse n° 3
        3 rue Jean d'Ormesson
        13003 Marseille
Adresse n° 4
        4 rue Jean d'Ormesson
        13003 Marseille

3-1-2-4. Automatiser les tests▲

use Test;
plan 1;
ok 2 * 2 == 4, "teste la multiplication 2 par 2";

ok 1 - teste la multiplication 2 par 2

Failed test 'teste la multiplication 2 par 2'

use Test;
plan 9;
my $nouvelle-rue = "rue Jean d'Ormesson";
my $cp = "13003";
my $ville = "Marseille";
my %nouv_adresses;
for 1, 3, 20, "12 bis" -> $num {
    %nouv_adresses{$num} = Adresse.new( 
        numéro => "$num",
        voie => $nouvelle-rue,
        code-postal => $cp,
        commune => $ville,
    );
    isa-ok  %nouv_adresses{$num}, Adresse,  
        "Test construction adresse pour $num";
    ok %nouv_adresses{$num}.numéro eq $num, 
        "Test sur le numero pour adresse $num";
} 
eval-dies-ok q[ %nouv_adresses{"string"} = Adresse.new( 
    numéro => "string",
    voie => $nouvelle-rue,
    code-postal => $cp,
    commune => $ville,
);], "Test exception lors de la construction";

1..9
ok 1 - Test construction adresse pour 1
ok 2 - Test sur le numero pour adresse 1
ok 3 - Test construction adresse pour 3
ok 4 - Test sur le numero pour adresse 3
ok 5 - Test construction adresse pour 20
ok 6 - Test sur le numero pour adresse 20
ok 7 - Test construction adresse pour 12 bis
ok 8 - Test sur le numero pour adresse 12 bis
ok 9 - Test exception lors de la construction

Nous voulons définir ici les personnes physiques (individus) et morales (entreprises, collectivités locales, établissements publics, etc.) qui peuvent être clients de la banque.

Une personne physique sera définie dans la classe Personne-privée, assez semblable à celle que nous avons déjà employée précédemment (voir par exemple la classe Personne du § 2.4). Nous pourrions vouloir la définir comme suit :

class Personne-privée {
    has Str $.nom;
    has Str $.prénom;
    has Adresse $.adresse is rw;
    has Str $.telephone-fixe is rw;
    # ...
    methode déménage {
        # changement d'adresse
    }
    # ...

Ici, on observe un exemple de composition de classes : la classe Personne-privée utilise un objet de la classe Adresse dans sa définition.

3-1-3-1. Un rôle pour les détails communs aux différentes sortes de personnes▲

role Personne-details {
    has Adresse $.adresse is rw;
    has NumString $.telephone-fixe is rw;

    method déménage (Adresse $nouvelle-adresse) {
        $.adresse = $nouvelle-adresse;
    }
    method change-telephone-fixe (NumString $num-appel) {
        $.telephone-fixe = $num-appel
    }
}

3-1-3-2. Définition de la classe des personnes physiques▲

class Personne-privée does Personne-details {
    has Str $.nom;
    has Str $.prénom;
    has Str $.sexe where {$_ eq "M"|"F"};
    has Date $.date-de-naissance;
    has Str $.lieu-de-naissance;
    has Str $.telephone-mobile is rw;

    method affiche-personne {dd self};
    method âge {sprintf "%d", (Date.today-$.date-de-naissance)/365.25}
    method affiche-personne-adresse {
        my $titre = $.sexe eq 'M' ?? "Monsieur" !! "Madame";
        say "\t$titre $!prénom $!nom";
        say $.adresse.affiche-adresse;
    }
}

my $xavier = Personne-privée.new(
    prénom => "Xavier",
    nom => "Sirvenne",
    sexe => "M",
    date-de-naissance => Date.new("1998-02-08"),
    lieu-de-naissance => "Brest",
    adresse => $adresse1,
    telephone-fixe => "04 01 02 03 04",
    telephone-mobile => "06 05 04 03 02",
);

$xavier.affiche-personne;
say "Âge de {$xavier.prénom} : {$xavier.âge} ans";
say "Adresse de {$xavier.prénom, $xavier.nom} :";
$xavier.affiche-personne-adresse;
say "Changement d'adresse";
$xavier.déménage($adresse2);
$xavier.affiche-personne-adresse;
say "Changement de téléphone fixe";
$xavier.change-telephone-fixe("04 02 03 04 05");
say "Nouveau numéro de téléphone de {$xavier.prénom, $xavier.nom} : ", $xavier.telephone-fixe;

Personne-privée.new(nom => "Sirvenne", prénom => "Xavier", sexe => "M", date-de-naissance => Date.new(1998,2,8), lieu-de-naissance => "Brest", telephone-mobile => "06 05 04 03 02", adresse => Adresse.new(numéro => "24 bis", voie => "rue des Fours à pain", commune => "Lyon", code-postal => "69007"), telephone-fixe => "04 01 02 03 04")
âge de Xavier : 20 ans
Adresse de Xavier Sirvenne :
        Monsieur Xavier Sirvenne
        24 bis rue des Fours à pain
        69007 Lyon
Changement d'adresse
        Monsieur Xavier Sirvenne
        42 rue Pasteur
        69007 Lyon
Changement de téléphone fixe
Nouveau numéro de téléphone de Xavier Sirvenne : 04 02 03 04 05

3-1-3-3. Sérialiser un objet▲

    method sérialise {
        "\t$!numéro $!voie\n" ~ 
        "\t$!code-postal $!commune";
    }

        24 bis rue des Fours à pain
        69007 Lyon

class Personne-privée does Personne-details {
    has Str $.nom;
    has Str $.prénom;
    has Str $.sexe where {$_ eq "M"|"F"};
    has Date $.date-de-naissance;
    has Str $.lieu-de-naissance;
    # has Adresse $.adresse is rw;
    # has Str $.telephone-fixe is rw;
    has Str $.telephone-mobile is rw;

    method civilité { 
        return $.sexe eq 'M' ?? "Monsieur" !! "Madame";
    }
    method âge { sprintf "%d", (Date.today - $.date-de-naissance)/365 }
    method sérialise-personne-adresse {
        my $titre = $.civilité;
        return "\t$titre $!prénom $!nom \n {$.adresse.sérialise-adresse}";
    }
    method affiche-personne-adresse {
        say $.sérialise-personne-adresse;
    }
    method sérialise-personne {
        my $né = $.sexe eq 'M' ?? "Né" !! "Née";
        my $naissance = (defined $.date-de-naissance && defined $.lieu-de-naissance) ??
                            "$né le $!date-de-naissance à $!lieu-de-naissance (âge = {$.âge} ans)\n" !!
                            "état-civil inconnu ou incomplet\n";
        my $personne-str = "{$.civilité} $!prénom $!nom\n" ~
                           "{$naissance}Adresse :\n" ~ 
                           $.sérialise-personne-adresse; 
        $personne-str ~= "\nTéléphone fixe : $!telephone-fixe" if defined $!telephone-fixe;
        $personne-str ~= "\nMobile : $!telephone-mobile"; # if defined $!telephone-mobile;
        return $personne-str;
    }
    method affiche-personne { say $.sérialise-personne };
}

Monsieur Xavier Sirvenne
Né le 1998-02-08 à Brest (âge = 20 ans)
Adresse :
        Monsieur Xavier Sirvenne
        24 bis rue des Fours à pain
        69007 Lyon
Téléphone fixe : 04 01 02 03 04
Mobile : 06 05 04 03 02

3-1-3-4. Surcharge de la méthode gist▲

Adresse.new(numéro => "24 bis", voie => "rue des Fours à pain", commune => "Lyon", code-postal => "69007")

class Adresse {
    has Str $.numéro where /^\d+ \s* [bis|ter]?$/;
    has Str $.voie;
    has Str $.commune;
    has NumString $.code-postal ;

    method gist {
        "\t$!numéro $!voie\n" ~ 
        "\t$!code-postal $!commune";
    }
}

say $adresse1;

        24 bis rue des Fours à pain
        69007 Lyon

3-1-3-5. Les personnes morales : création par héritage▲

class Personne-morale does Personne-details {
    has Str $.nom is rw;
    has Personne-privée $.contact is rw;
    has Date $.date-de-création;
    has Date $.date-de-dissolution is rw = Date; # non définie à la création
    
    method dissout (Date $date-de-fin) {
        $.date-de-dissolution = $date-de-fin;
    }
    method sérialise {
        qq:to/END/;
        Nom : {$!nom.gist}
        Adresse :\n {$.adresse.sérialise}
        Téléphone : $!telephone-fixe
        Contact: {$!contact.prénom, $!contact.nom}
        Date de création :  $.date-de-création
        END
    }
}

my $assoc = Personne-morale.new(
    nom => "Club de photo de Trifouilly-les-Oies",
    contact => $xavier,
    date-de-création => Date.new("2015-11-15"),
    adresse => $adresse2,
    telephone-fixe => $xavier.telephone-fixe,
);
say $assoc.sérialise;

Nom : Club de photo de Trifouilly-les-Oies
Adresse :
        42 rue Pasteur
        69007 Lyon
Téléphone : 04 02 03 04 05
Contact: Xavier Sirvenne
Date de création :  2015-11-15

class Entreprise is Personne-morale {
    has Int $.capital is rw; # le capital social peut changer
    has NumString $.siret;
    has Personne-privée $.gérant is rw;
    has Str $.secteur-d'activité;
    # ...  
    method modifie-capilal (Int $nouveau-capital) {
        $!capital = $nouveau-capital;
    }
    method nouveau-gérant (Personne-privée $nouv-gérant) {
        $!gérant = $nouv-gérant;
    }
    # ...
}

class Association is Personne-morale {
    has Str $.activité;
    has Personne-privée $.présidence is rw;
    # ...
    method nouvelle-présidence (Personne-privée $nouv-prés) {
        $!présidence = $nouv-prés;
    }
    method gist {
        my $assoc_str = $.sérialise; # héritée de Personne-morale
        $assoc_str ~= "Activité : $!activité\n";
        $assoc_str ~= "Présidence: {$.présidence.sérialise-personne}\n";       
    }    
}

class Municipalité is Personne-morale {
    has Personne-privée $.maire is rw
    # ...
}

class Établissement-public is Personne-morale {
    has Personne-privée $.directeur is rw;
    # ...
}

my $assoc-photo = Association.new(
    nom => "Club de photo de Trifouilly-les-Oies",
    activité => "Clup photographique",
    adresse => $adresse2,
    présidence => Personne-privée.new(
        prénom => "Patricia",
        nom => "Kernevéo",
        sexe => "F",
        adresse => @nouv_adresses[4],
        telephone-mobile => "06 08 07 06 05",
    ),
    contact => $xavier,
    date-de-création => Date.new("2015-11-15"),
    adresse => $adresse2,
    telephone-fixe => $xavier.telephone-fixe,
);
say $assoc-photo;

Nom : Club de photo de Trifouilly-les-Oies
Adresse :
        42 rue Pasteur
        69007 Lyon
Téléphone : 04 01 02 03 04
Contact: Xavier Sirvenne
Date de création :  2015-11-15
Activité : Clup photographique
Présidence: Madame Patricia Kernevéo
état-civil inconnu ou incomplet
Adresse :
        Madame Patricia Kernevéo
        4 rue Jean d'Ormesson
        13003 Marseille
Mobile : 06 08 07 06 05

3-1-3-6. Les personnes morales : création par application de rôle▲

role Pers-morale-role does Personne-details { 
    has Str $.nom is rw;
    has Personne-privée $.contact is rw;
    has Date $.date-de-création;
    has Date $.date-de-dissolution is rw = Date; # non définie à la création
    
    method dissout (Date $date-de-fin) {
        $.date-de-dissolution = $date-de-fin;
    }
    method sérialise {
        qq:to/END/;
        Nom : $!nom
        Adresse :\n {$.adresse.sérialise}
        Téléphone : {$.telephone-fixe}
        Contact: {$!contact.prénom, $!contact.nom}
        Date de création :  $.date-de-création
        END
    }
}

class Entreprise does Pers-morale-role {
    has Int $.capital is rw; # le capital social peut changer
    has NumString $.siret;
    has Personne-privée $.gérance is rw;
    has Str $.secteur-d'activité; 
    # ...  
    method modifie-capital (Int $nouveau-capital) {
        $!capital = $nouveau-capital;
    }
    method nouveau-gérant (Personne-privée $nouv-gérant) {
        $!gérance = $nouv-gérant;
    }
    method gist {
        qq:to/FIN/;
        {$.sérialise}
        Secteur d'activité : $!secteur-d'activité
        Siret : $!siret
        Gérance = {$.gérance.sérialise-personne}
        FIN
    }
    # ...
}

my $sarl = Entreprise.new(
    nom => "SARL Belkacem Frères",
    secteur-d'activité => "Restauration",
    siret => "507865432 10",
    adresse => Adresse.new( 
        numéro => "7 bis",
        voie => "rue Léon Gambetta",
        code-postal => "69100",
        commune => "Villeurbanne",
    ),
    gérance => Personne-privée.new(
        prénom => "Yacine",
        nom => "Belkacem",
        sexe => "M",
        adresse => @nouv_adresses[5],
        telephone-mobile => "06 08 07 06 07",
    ),
    contact => Personne-privée.new(
        prénom => "Fadila",
        nom => "Belkacem",
        sexe => "F",
        adresse => @nouv_adresses[5],
        telephone-mobile => "06 08 07 06 08",
    ),        
    date-de-création => Date.new("2013-05-16"),
    telephone-fixe => "04 09 08 07 06",
);    
say $sarl;

Nom : SARL Belkacem Frères
Adresse :
        7 bis rue Léon Gambetta
        69100 Villeurbanne
Téléphone : 04 09 08 07 06
Contact:
        Madame Fadila Belkacem
        5 rue Jean d'Ormesson
        13003 Marseille
        06 08 07 06 08
Date de création :  2013-05-16

Secteur d'activité : Restauration
Siret : 507865432 10
Gérance = Monsieur Yacine Belkacem
état-civil inconnu ou incomplet
Adresse :
        Monsieur Yacine Belkacem
        5 rue Jean d'Ormesson
        13003 Marseille
Mobile : 06 08 07 06 07

3-1-3-7. Héritage ou application de rôle ?▲

class Personne-morale does Personne-details {
    # même code que précédemment
}

role SAS {
    has Int $.capital is rw;
    has Personne-privée $.directeur is rw;
    # ...
}

my $société-simplifiée = Personne-morale.new(
    nom => "Transport international SAS",
    contact => $xavier,
    date-de-création => Date.today,
);
$société-simplifiée does SAS;
$société-simplifiée.directeur = $xavier;
$société-simplifiée.capital = 100_000;
dd $société-simplifiée;

Une première idée est de créer une classe parente générique contenant tout ce qui est commun à toutes les sortes de clients et de définir ensuite des classes filles traitant les particularités propres à chaque type de client.

Nous définissons donc une classe générique Client, définissant tout ce qui est commun aux différents types de clients, et dérivons ensuite deux classes filles, Client-privé et Client-société :

class Client {
    has NumString $.num_client;
    has Date $.date-d'activation;
    has Date $.date-désactivation is rw = now.Date; # 
    has Bool $.client-actif is rw = True; # valeur par défaut à la construction
    
    method sérialise-client {
        my $détails-client = "Numéro de client : $.num_client\n"
                           ~ "Date d'activation : $.date-d'activation\n"
                           ~ "Client actif : {$.client-actif ?? 'Oui' !! 'Non'} \n";
        $détails-client  ~= "Date de désactivation = $.date-désactivation\n" unless $.client-actif;
        return $détails-client;
    }

    method résilie-client (Date $date-désact = Date.today) {
        $!date-désactivation = $date-désact;
        $.client-actif = False;
    }
}


class Client-privé is Client {
    has Personne-privée $.personne;
    
    method sérialise {
        my $détails = $.sérialise-client ~ $.personne.sérialise-personne;
        return $détails;
    }
}

class Client-société is Client {
    has Entreprise $.société is rw;  # une société peut changer de raison sociale

    method sérialise {
        return $.sérialise-client ~ $.société.gist;
     }
}

Voici un test très simple d'utilisation de ces classes, réutilisant la société $sarl définie précédemment :

my $cli-sarl = Client-société.new(
    société => $sarl,
    num_client => "0123456789",
    date-d'activation => Date.new("2015-11-14")
);

say $cli-sarl.sérialise;

La dernière instruction du code ci-dessus affiche ce qui suit :

Numéro de client : 0123456789
Date d'activation : 2015-11-14
Client actif : Oui
Nom : SARL Belkacem Frères
Adresse :
        7 bis rue Léon Gambetta
        69100 Villeurbanne
Téléphone : 04 09 08 07 06
Contact:
        Madame Fadila Belkacem
        5 rue Jean d'Ormesson
        13003 Marseille
        06 08 07 06 08
Date de création :  2013-05-16

Secteur d'activité : Restauration
Siret : 507865432 10
Gérance = Monsieur Yacine Belkacem
état-civil inconnu ou incomplet
Adresse :
        Monsieur Yacine Belkacem
        5 rue Jean d'Ormesson
        13003 Marseille
Mobile : 06 08 07 06 07

On constate que cela fonctionne plutôt bien.

À titre d'exercice, nous recommandons au lecteur de tester notamment l'instanciation d'un objet de type Client-privé et la résiliation d'un compte-client. Vous pouvez également définir d'autres types de clients associés aux autres types de personnes morales définies précédemment.

Dans cet exemple, le numéro de client est passé en paramètre par le code utilisateur au constructeur de la classe. Dans une application réelle, il serait sans doute préférable que la classe Client génère elle-même un nouveau numéro de client. Nous verrons plus loin (voir § 4.1.6) une solution possible pour mettre en œuvre un générateur automatique de numéros de client.

Cette mise en œuvre nous pose cependant un petit problème conceptuel : la classe Client que nous avons créée ne sert pas à grand-chose (à part fournir une classe parente pour permettre l'héritage de classes filles). Nous pouvons en principe instancier un objet de cette classe, mais celui-ci ne sera relié à aucune personne (morale ou physique) réelle et ne servira donc à rien dans le monde réel : un client ne correspondant pas à une personne est très théorique et parfaitement inutile.

D'un point de vue conceptuel, notre classe Client est une classe générique (permettant l'héritage) et abstraite : on ne peut rien créer d'utile avec elle. Mais, syntaxiquement, on peut néanmoins instancier des objets appartenant à cette classe. Ce n'est peut-être pas très satisfaisant.

Il est sans doute préférable de ne pas encourager la création de ce genre d'entité. Une solution pourrait être de définir l'entité « client » comme un rôle, qui représente un peu plus l'idée d'une classe abstraite.

Par rapport à ce qui précède, la syntaxe est presque la même, il n'y a que trois lignes de code qui sont modifiées.

role Client {                             # c'est maintenant un rôle
    # exactement le même code que la classe Client utilisée ci-dessus
}
class Client-privé does Client {          # does au lieu de is
    # même code que précédemment
}

class Client-société does Client {        # does au lieu de is
    # même code que précédemment
}

Avec le même jeu de test, nous obtenons le même résultat que nous ne répéterons pas ici (mais le lecteur est invité à essayer).

En fait, cela fonctionne exactement de la même façon, la seule différence est qu'utiliser un rôle au lieu d'une classe mère suggère un peu plus clairement qu'il n'y a pas lieu d'instancier Client. À vrai dire, la différence n'est que sémantique ; syntaxiquement, on peut très bien promouvoir un rôle au rang de classe et, par conséquent, instancier un rôle (voir § 4.2.3), mais on peut penser que l'utilisateur s'interrogera avant d'instancier un rôle et comprendra que l'idée est celle d'une classe générique abstraite, en principe non destinée à être instanciée.

D'un point de vue syntaxique, la différence est que si deux méthodes ont le même nom (une situation que nous avons évitée ici), la résolution sera résolue par héritage dans le cas des classes mères et filles, alors que le conflit de noms générera dès la compilation une erreur dans le cas d'application de rôle. Comme nous l'avons déjà dit, nous préférons largement cette seconde situation : mieux vaut une erreur de compilation d'entrée de jeu qu'un bug discret et subtil passant facilement inaperçu lors des tests.

Comme précédemment, nous pourrions envisager d'autres modélisations. Par exemple, nous pouvons créer une classe Client et, comme dans le cas de la classe Personne-morale ci-dessus, appliquer les rôles Client-privé et Client-société à nos objets de la classe Client. Cela fonctionne, mais la syntaxe tend à être (comme précédemment) un peu moins attrayante. Ces autres modélisations pourraient être parfaitement satisfaisantes pour d'autres cas de figure.

La définition d'une classe Compte ressemble à ce que nous avons fait précédemment et ne présente pas de difficulté particulière. Par exemple, nous pouvons faire ceci :

class Compte {
    has NumString $.num-compte;
    has Client $.client-titulaire;
    has Date $.date-d'activation-compte;
    has Date $.date-de-résiliation-compte is rw;
    has Rat $.solde is rw;
    has Bool $.compte-actif is rw = True;
    
    method dépose (Rat $dépôt) {
        $.solde += $dépôt;
    }
    method retire (Rat $retrait) {
        say "Solde $.solde insuffisant pour retrait de $retrait" 
            and return -1 if $retrait > $.solde;
        $.solde -= $retrait;
        return $.solde;
    }
    method résilie (Date $date) {
        # ...
    }
    method sérialise-compte {
        my $détails-compte = "Numéro de compte : $.num-compte\n";
        $détails-compte ~= "Date d'activation du compte : $.date-d'activation-compte\n";
        $détails-compte ~=  $.client-titulaire.sérialise-client;
        $détails-compte ~=  "Solde du compte : $.solde \n";
    }
}

Nous pouvons tester le fonctionnement général d'un compte bancaire comme suit :

my $compte-bancaire = Compte.new(
    num-compte => "987654321",
    client-titulaire => $cli-sarl,
    solde => 500.00,
    date-d'activation-compte => Date.new("2018-02-15"),
); 

say $compte-bancaire.sérialise-compte;
$compte-bancaire.retire(400.25);
say "Solde après premier retrait : ", $compte-bancaire.solde;
$compte-bancaire.dépose(100.25);
say "Solde après premier dépôt : ", $compte-bancaire.solde;
my $resultat = $compte-bancaire.retire(400.Rat);
say "Retrait impossible" if $resultat <0;

L'affichage est conforme à nos attentes :

Numéro de compte : 987654321
Date d'activation du compte : 2018-02-15
Numéro de client : 0123456789
Date d'activation : 2015-11-14
Client actif : Oui
Solde du compte : 500

Solde après premier retrait : 99.75
Solde après premier dépôt : 200
Solde 200 insuffisant pour retrait de 400
Retrait impossible

Nous pouvons créer d'autres types de comptes bancaires.

Par exemple, la classe Compte créée à la section précédente utilise un attribut $.client-titulaire de type Client générique. À titre d'exercice, vous pouvez créer des types de comptes bancaires spécifiques aux différents types de clients que nous avons créés précédemment (Client-société et Client-privé) ou ceux que vous avez créés de votre côté. Cela ne devrait nécessiter que quelques minutes de travail et quelques lignes de code. Une solution possible est fournie un peu plus loin (voir § 3.3.4).

Ce n'est un secret pour personne que les banquiers aiment beaucoup facturer des frais bancaires et qu'ils ont dans ce domaine presque autant d'imagination que le ministère des Finances en matière de création de nouvelles taxes ou redevances.

Supposons que nous voulions facturer des frais de 0,50 € pour chaque retrait effectué. Nous pourrions créer un nouveau type de compte héritant de la classe Compte et redéfinissant la méthode retire pour y ajouter le prélèvement de cette commission. Cela ne présente guère de difficulté.

Toutefois, connaissant les banquiers, nous soupçonnons qu'ils voudront certainement imposer ce genre de frais bancaires à plusieurs sortes de comptes. Il est donc peut-être préférable de définir un rôle gérant ce genre de commission bancaire et qui pourra s'appliquer à différents types de comptes.

3-3-3-1. Frais bancaire codé en dur▲

role Frais-bancaire {
  method retire (Rat $retrait) {
    say "Solde $.solde insuffisant pour retrait de $retrait" 
        and return -1 if $retrait > $.solde;
    say "Retrait avec frais";
    $.solde -= $retrait + 0.50; # 0,50: frais (codé en dur)
    return $.solde;
  }
}

class Compte-avec-frais is Compte does Frais-bancaire {};

3-3-3-2. Un rôle paramétré▲

role Frais-bancaire [Rat $amount] {
  method retire (Rat $retrait) {
    say "Solde $.solde insuffisant pour retrait de $retrait" 
        and return -1 if $retrait > $.solde;
    say "Retrait avec frais";
    $.solde -= $retrait + $amount; # $amount: frais passé en argument 
    return $.solde;
  }
}

class Compte-avec-frais is Compte does Frais-bancaire[0.5] {};

my $compte-bancaire = Compte-avec-frais.new(
    num-compte => "987654321",
    client-titulaire => $cli-sarl,
    solde => 500.00,
    date-d'activation-compte => Date.new("2018-02-15"),
); 

$compte-bancaire.retire(400.00);
say "Solde après premier retrait : ", $compte-bancaire.solde;
$compte-bancaire.dépose(100.00);
say "Solde après premier dépôt : ", $compte-bancaire.solde;
my $resultat = $compte-bancaire.retire(400.Rat);
say "Retrait impossible" if $resultat <0;

Retrait avec frais
Solde après premier retrait : 99.5
Solde après premier dépôt : 199.5
Solde 199.5 insuffisant pour retrait de 400
Retrait impossible

Cette section propose une solution possible à l'exercice proposé au § 3.3.2. Il s'agit de créer des types de comptes bancaires spécifiques aux différents types de clients précédemment, comme Client-privé.

Il suffit de créer une nouvelle classe héritant de Client et redéfinissant l'attribut client-titulaire :

class Compte-privé is Compte {
    has Client-privé $.client-titulaire;
}

Cela fonctionne bien, mais nous laissons, à titre d'exercice complémentaire, au lecteur le soin d'instancier un objet de la classe Client-privé puis un objet de la classe Compte-privé pour tester l'ensemble. Toujours à titre d'exercice, le lecteur est invité à créer un type de compte privé faisant l'objet de frais bancaires de 1 euro pour chaque retrait. Indice : le lecteur devrait constater à cette occasion l'intérêt qu'il y avait de créer un rôle paramétré pour gérer les frais bancaires.

On déclare une classe à l'aide du mot-clef class, généralement suivi du nom de la classe :

class Voyage {
    # ...
}

Cette déclaration crée un objet-type et l'installe dans le paquetage courant et dans la portée lexicale courante sous le nom Voyage.

Il y a en fait deux façons principales de déclarer des classes. La première commence par la déclaration Class NomClasse; et s'étend jusqu'à la fin du fichier :

class NomClasse;
# la définition de la classe commence ici

Dans la seconde forme, le nom de la classe est suivi d'un bloc, et tout ce qui se trouve dans ce bloc constitue la définition de la classe :

class NomClasse {
    # définition de la classe dans ce bloc
}
# autres définitions de classes ou code autre

Cette seconde forme permet éventuellement de définir plusieurs classes (de préférence apparentées) dans le même fichier.

Il est également possible de déclarer des classes de portée lexicale :

my class Voyage {
    # ...
}

Ceci limite la visibilité de la classe à la portée lexicale courante, ce qui peut s'avérer utile si la classe est un détail de mise en œuvre à l'intérieur d'un module ou d'une autre classe.

Nous avons dit dans la section précédente que la définition d'une classe crée un objet-type. Que voulons-nous dire et quelles sont les conséquences ?

En fait, les types eux-mêmes sont des objets et il est possible d'obtenir l'objet-type en écrivant simplement son nom :

my $obj-type-int = Int;      # -> (Int)

Il est possible de connaître l'objet-type d'un objet quelconque en appelant la méthode WHAT (qui est en fait une macro sous la forme d'une méthode) :

my $obj-type-int = 1.WHAT;   # -> (Int)

Il est possible de vérifier si des objets-types (à l'exception de Mu, le type au sommet de la hiérarchie des types dont héritent tous les autres) sont égaux à l'aide de l'opérateur d'identité === :

sub f(Int $x) {
    if $x.WHAT === Int {
        say 'Vous avez passé un Int';
    }
    else {
        say 'Vous avez passé un sous-type de Int';
    }
}

En vérité, dans la majeure partie des cas courants, la méthode .isa sera suffisante et plus simple d'utilisation :

sub f($x) {
    if $x.isa(Int) {
        ...
    }
    ...
}

La vérification des sous-types se fait avec l'opérateur de comparaison intelligente ~~ (smart match) :

my Int $i = 5;
say "Compatible avec réel" if $i ~~ Real; # Int est sous-type de Real
# -> "Compatible avec réel" (Int hérite des méthodes de Real)

Les attributs sont des variables privées qui existent à l'intérieur des membres d'une classe (et que possèdent tous les objets instanciant ladite classe). Ce sont eux qui stockent l'état d'un objet. En Perl 6, tous les attributs sont privés. On les déclare généralement avec le mot-clef has et en utilisant le twigil « ! » :

class Voyage {
    has $!point-de-départ;
    has $!destination;
    has @!voyageurs;
    has $!notes;
}

Il n'existe pas en Perl 6 d'attribut public (ou même protégé) à proprement parler, mais il existe une manière de générer automatiquement des accesseurs (méthodes d'accès) : il suffit de remplacer le twigil « ! » par le twigil « . » (moyen mnémotechnique : le « . » devrait vous faire penser à un appel de méthode) :

class Voyage {
    has $.point-de-départ;
    has $.destination;
    has @!voyageurs;
    has $.notes;
}

Ceci fournit par défaut des accesseurs en lecture seule. Pour autoriser des modifications de l'attribut, il faut ajouter le trait is rw :

class Voyage {
    has $.point-de-départ;
    has $.destination;
    has @!voyageurs;
    has $.notes is rw;
}

Désormais, une fois un objet Voyage créé, ses attributs .point-de-départ, .destination et .notes seront accessibles depuis l'extérieur de la classe via les accesseurs, mais seul l'attribut .notes sera modifiable.

L'attribut @!voyageurs reste privé et inaccessible depuis l'extérieur de la classe : seule une méthode interne à la classe pourra y accéder. Ce tableau n'est pas déclaré avec le trait is rw et n'est donc en principe pas mutable, mais c'est le container (le tableau lui-même) qui ne peut pas être modifié, nous verrons dans un exemple prochainement qu'il reste tout à fait possible pour une méthode de la classe de modifier le contenu (les éléments du tableau). La distinction est subtile et, dans la pratique, on peut considérer que les attributs de type tableau se comportent comme s'ils étaient modifiables pour les utilisations les plus courantes.

Comme les classes héritent d'un constructeur par défaut de Mu et comme nous avons demandé que des accesseurs soient générés pour nous, notre classe est déjà presque fonctionnelle :

# Création d'une nouvelle instance de la classe
my $vacances = Voyage.new(
    point-de-départ  => 'Suède',
    destination      => 'Suisse',
    notes            => 'Équipement type camping!'
);

# Utilisation d'un accesseur : 
say $vacances.point-de-départ;    # -> Suède

# Utilisation d'un accesseur de type rw pour modifier la valeur:
$vacances.notes = 'Équipement type camping plus lunettes de soleil';

À noter que le constructeur par défaut n'alimentera que les attributs qui ont un accesseur, (donc déclarés avec le twigil $.), mais il peut initialiser des attributs en lecture seule (c'est même le seul moment où l'on pourra leur donner une valeur).

On déclare une méthode à l'aide du mot-clef method à l'intérieur du corps d'une classe :

class Voyage {
    has $.départ;
    has $.destination;
    has @!voyageurs;
    has $.notes is rw;

    method ajoute_voyageur($nom) {
        if $nom ne any(@!voyageurs) {
            push @!voyageurs, $nom;
        }
        else {
            warn "$nom est déjà du voyage!";
        }
    }
    method décrire() {
        join " ", "De", $!départ, "à", $!destination,
                  "- Voyageurs:", @!voyageurs;
    }
}

La classe peut être appelée comme suit :

my $week-end-amoureux = Voyage.new(départ      => "Paris", 
                                   destination => "Londres");
$week-end-amoureux.ajoute_voyageur($_) for <Roméo Juliette Roméo>;
say $week-end-amoureux.perl;
say "Ajoute une note";
$week-end-amoureux.notes = "Eurostar";
say $week-end-amoureux.perl;
say $week-end-amoureux.décrire;

Ce qui affiche :

Roméo est déjà du voyage!  in method ajoute_voyageur at voyage.pl6:12
Voyage.new(départ => "Paris", destination => "Londres", notes => Any)
Ajoute une note
Voyage.new(départ => "Paris", destination => "Londres", notes => "Eurostar")
De Paris à Londres - Voyageurs: Roméo Juliette

On constate que le programme avertit à propos du voyageur (Roméo) ajouté par erreur une seconde fois. L'ajout d'une note directement depuis le code appelant ne pose pas de problème, car c'est un attribut « public » (plus précisément doté d'un accesseur par défaut) et il est déclaré en mode rw. L'appel de méthode $week-end-amoureux.perl renvoie les seuls attributs publics tandis que l'appel de la méthode décrire permet aussi de connaître le nom des tourtereaux partant en week-end.

Une méthode peut avoir une signature, tout comme une fonction (subroutine). Les attributs sont utilisables dans des méthodes et peuvent toujours être employés avec le twigil « ! », même s'ils ont été déclarés avec le twigil « . » (comme dans la méthode décrire de l'exemple ci-dessus). La raison en est qu'en fait, le twigil « . » déclare un twigil « ! » et génère en outre un accesseur. Autrement dit, les attributs « publics » ne sont en fait rien d'autres que des attributs privés dotés d'un accesseur public.

Il y a une différence subtile, mais importante entre, par exemple, les expressions $!départ et $.départ dans la méthode décrire. La première syntaxe effectue toujours une simple recherche sur la valeur de l'attribut. Cela ne coûte pas grand-chose et vous savez que c'est l'attribut déclaré dans la classe. Cette syntaxe n'est utilisable qu'à l'intérieur de la classe.

La seconde syntaxe, avec le « . », est en fait un appel de méthode et peut donc être utilisée ailleurs dans le programme ou redéfinie (overriden) dans une classe fille. Il faut par conséquent utiliser uniquement $.départ si l'on désire explicitement autoriser une redéfinition de la méthode dans une classe fille.

À l'intérieur d'une méthode, il est possible d'utiliser le terme self qui est lié à l'objet invoquant, c'est-à-dire à l'objet sur lequel la méthode a été appelée. self peut être utilisé pour appeler d'autres méthodes sur l'invoquant. À l'intérieur d'une méthode, $ est également lié à l'objet invoquant, si bien la syntaxe $.point-de-départ est équivalente à self.point-de-départ.

4-1-6-1. Attributs de classe▲

class Employé {
    has Personne $.données-personnelles;
    has Numeric $.matricule;
    has Str $.intitulé-poste is rw;
    has Numeric $.salaire is rw;
    # ...    
}

my $salarié = Employé.new(
    données-personnelles => Personne.new(
        # ... données personnelles du salarié
    ),
    matricule => 12345,
    intitulé-poste => "technicien de surface",
    salaire => 1234.5
);

class Employé {
    my $matricule-courant = 0;
    has Personne $.données-personnelles;
    has Numeric $.matricule;
    has Str $.intitulé-poste is rw;
    has Numeric $.salaire is rw;
    # ...
    
    method nouveau-matricule { ++$matricule-courant; }
    
}

my $salarié = Employé.new(
    données-personnelles => Personne.new(
        nom => "Jean",
        prénom => "Chiponelli",
        sexe => "M",
        date-de-naissance => Date.new(1992, 10, 24),
        lieu-de-naissance => "Strasbourg",
        adresse => Adresse.new( numéro => 42, voie => "boulevard Carnot", 
                                commune => "Nice", code-postal => "06000"
        ),
        numéro-sécu => "1-92-10-67...",  telephone-personnel => "0712345678" 
    ),
    matricule => Employé.nouveau-matricule(),
    intitulé-poste => "technicien de surface",
    salaire => 1234.5
);
say "Matricule de l'employé : {$salarié.matricule}";

Matricule de l'employé : 1

class Employé {
    my $matricule-courant = 0;
    has Personne $.données-personnelles;
    has Numeric $.matricule = ++$matricule-courant;
    # ... 
}

    has Numeric $.matricule = ++$matricule-courant;

my $salarié = Employé.new(
    données-personnelles => Personne.new(
        nom => "Jean",
        prénom => "Chiponelli",
        sexe => "M",
        date-de-naissance => Date.new(1992, 10, 24),
        lieu-de-naissance => "Strasbourg",
        adresse => Adresse.new( numéro => 42, voie => "boulevard Carnot", 
                                commune => "Nice", code-postal => "06000"
        ),
        numéro-sécu => "1-92-10-67...",  telephone-personnel => "0712345678" 
    ),
    intitulé-poste => "technicien de surface",
    salaire => 1234.5
);
say "Matricule de l'employé : {$salarié.matricule}";

4-1-6-2. Méthodes de classe▲

class Employé {
    my $matricule-courant = 0;
    has Personne $.données-personnelles;
    has Numeric $.matricule = nouveau-matricule();
    has Str $.intitulé-poste is rw;
    has Numeric $.salaire is rw;
    # ...
    sub nouveau-matricule { return ++$matricule-courant }
}

class Employé {
    my $matricule-courant = 0;
    has Personne $.données-personnelles;
    has Numeric $.matricule = nouveau-matricule();
    has Str $.intitulé-poste is rw;
    has Numeric $.salaire is rw;
    # ...
    sub nouveau-matricule { return ++$matricule-courant; }
    our sub valeur-matricule-courant { return $matricule-courant; }
}

say "Matricule courant = ", Employé.valeur-matricule-courant; # ERREUR
# Undeclared routine:
#     valeur-matricule-courant used at line 78

say "Matricule courant = ", Employé::valeur-matricule-courant;

Les méthodes déclarées avec un point d'exclamation « ! » sont privées, c'est-à-dire qu'elles ne peuvent être invoquées que depuis l'intérieur de la classe (et non de l'extérieur). On les appelle avec un point d'exclamation au lieu d'un simple point :

method !action-privée($x) {
    ...
}
method publique($x) {
    if self.précondition {
        self!action-privée(2 * $x)
    }
}

Les méthodes privées ne sont pas accessibles depuis l'extérieur de la classe (c'est leur but) et ne sont pas non plus héritées dans les classes filles.

Les subméthodes (submethods) sont des méthodes publiques qui ne sont pas héritées dans les classes filles. Leur dénomination émane du fait qu'elles sont sémantiquement équivalentes à des fonctions (subroutines), ce sont presque des fonctions, la seule différence étant qu'elles sont invoquées avec une syntaxe de méthode.

Les subméthodes sont utiles pour accomplir des tâches de construction et de destruction d'objets, ainsi que pour des tâches qui sont si spécifiques à un type donné que les sous-types devront certainement les redéfinir.

Par exemple, le constructeur par défaut new appelle la subméthode BUILD sur chaque classe de la chaîne d'héritage :

class Point2D {
    has $.x;
    has $.y;

    submethod BUILD(:$!x, :$!y) {
        say "Initialise Point2D";
    }
}

class Point2DInversible is Point2D {
    submethod BUILD() {
        say "Initialise Point2DInversible";
    }
    method inverse {
        self.new(x => - $.x, y => - $.y);
    }
}
my $pt_inv =  Point2DInversible.new(x => 1, y => 2);
say $pt_inv.inverse.perl;

Ce qui affiche :

Initialise Point2D
Initialise Point2DInversible
Point2DInversible.new(x => -1, y => -2)

Nous avons vu au § 2.2 que les classes peuvent avoir des classes mères (ou super-classes), dont elles héritent éventuellement. La classe mère est spécifiée à l'aide du trait is. Ci-dessous un exemple d'héritage multiple (voir nos réserves à propos de l'héritage multiple au § 2.2.3) dans lequel la classe Enfant hérite des classes mères Parent1 et Parent2 :

class Enfant is Parent1 is Parent2{ }

Si l'on appelle sur une classe fille une méthode qui n'est pas définie dans cette classe fille, alors c'est une méthode ayant le même nom dans l'une des classes mères qui sera appelée, si elle existe (sauf si la méthode est définie dans un rôle attribué à la classe ou à l'objet, auquel cas Perl n'ira pas consulter les classes mères). C'est ce que l'on appelle l'héritage. L'ordre dans lequel les classes mères sont consultées s'appelle l'ordre de résolution des méthodes (method resolution order ou MRO). Perl 6 utilise la méthode C3 de résolution. Il est possible de connaître cet ordre pour un type donné grâce à un appel à sa métaclasse :

say Int.^mro;    # (Int) (Cool) (Any) (Mu)

Si une classe ne spécifie pas de classe mère, alors la classe Any est sa classe mère par défaut. Toutes les classes héritent directement ou indirectement de Mu, la racine de la hiérarchie des types.

Tous les appels aux méthodes publiques sont virtuels au sens C++ du terme, ce qui signifie que c'est le type réel de l'objet qui détermine quelle méthode invoquer, et non son type déclaré :

class Parent {
    method farfouille {
        say "méthode farfouille de la classe mère"
    }
}

class Enfant is Parent {
    method farfouille {
        say "Appel de la méthode farfouille de la classe fille"
    }
}

my Parent $test;
$test = Enfant.new;
$test.farfouille;   # appelle la méthode farfouille de la classe fille
# affiche :  Appel de la méthode farfouille de la classe fille

Les objets sont généralement créés au moyen d'appels de méthodes, soit sur l'objet-type, soit sur un autre objet de même type.

La classe Mu fournit un constructeur, la méthode new, qui prend en paramètres des arguments nommés et les utilise pour initialiser les attributs « publics » :

class Point {
    has $.x;
    has $.y = 2 * $!x;   # valeur par défaut de $y si non spécifiée
}

my $p = Point.new( x => 1, y => 2);
#             ^^^ méthode héritée de la classe Mu
say "x: ", $p.x;    # -> x: 1
say "y: ", $p.y;    # -> y: 2

my $p2 = Point.new( x => 5 );
# la valeur sert à calculer $y si l'argument $y n'est pas fourni
# value for y.
say "x: ", $p2.x;   # -> x: 5
say "y: ", $p2.y;   # -> y: 10

Mu.new appelle la méthode bless sur l'argument invoquant et passe tous les arguments nommés. La méthode bless crée le nouvel objet et invoque ensuite la méthode BUILDALL sur cet objet. BUILDALL parcourt alors l'arbre des classes filles en ordre inverse du MRO (c'est-à-dire depuis Mu jusqu'à la classe la plus dérivée) et, pour chacune de ces classes, vérifie l'existence d'une classe BUILD. Si elle existe, elle est appelée avec pour paramètres les arguments nommés reçus par new. Sinon, les attributs publics de cette classe sont initialisés avec les arguments nommés ayant le même nom. Dans les deux cas, si ni BUILD, ni le mécanisme par défaut n'a initialisé l'attribut, alors les valeurs par défaut sont utilisées (l'instruction $.y = 2 * $!x dans l'exemple ci-dessus).

En raison de la nature du comportement par défaut de la subméthode générale BUILDALL et des subméthodes customisées BUILD, les arguments nommés passés au constructeur new dérivé de Mu correspondent directement aux attributs publics de n'importe quelle classe du MRO, ou à tout paramètre nommé passé à toute subméthode BUILD.

Ce mécanisme de construction des objets entraîne plusieurs conséquences pour les constructeurs sur mesure. D'abord, les méthodes customisées BUILD doivent toujours être des subméthodes, faute de quoi elles empêcheraient l'initialisation des attributs dans les sous-classes. Deuxièmement, les subméthodes BUILD peuvent être utilisées pour lancer du code spécifique lors de la construction de l'objet. Elles peuvent également servir à créer des alias pour l'initialisation des attributs :

class EncodedBuffer {
    has $.enc;
    has $.data;

    submethod BUILD(:encodage(:$enc), :$data) {
        $!enc  :=  $enc;
        $!data := $data;
    }
}
my $b1 = EncodedBuffer.new( encodage => 'UTF-8', data => [64, 65] );
my $b2 = EncodedBuffer.new( enc      => 'UTF-8', data => [64, 65] );
#  enc et encodage sont maintenant tous les deux autorisés

Comme le passage d'arguments à une routine lie les arguments aux paramètres, l'étape supplémentaire de liaison n'est pas nécessaire si c'est l'attribut lui-même qui est utilisé en tant que paramètre. Il en résulte que l'exemple ci-dessus aurait pu s'écrire plus simplement :

    submethod BUILD(:encodage(:$!enc), :$!data) {
        # plus rien à faire ici, la liaison de la signature
        # fait tout le travail pour nous
    }

La troisième conséquence est que si l'on désire un constructeur qui accepte des arguments positionnels, il faut alors écrire sa propre méthode new :

    class Point {
        has $.x;
        has $.y;
        method new($x, $y) {
            self.bless(:$x, :$y);
        }
    }

Cette pratique n'est cependant pas encouragée, car elle rend plus difficile l'initialisation des objets instanciant des classes filles.

À noter également que le nom new n'a rien de particulier en Perl 6. C'est une simple convention commune. Vous pouvez appeler bless depuis n'importe quelle méthode, ou utiliser CREATE pour faire du bidouillage de bas niveau.

Une autre façon possible de tripatouiller la création d'objets est d'écrire une méthode BUILDALL spécifique. Pour garantir que l'initialisation des classes mères fonctionne correctement, il faut appeler callsame afin d'invoquer la subméthode BUILDALL des classes mères :

class MaClasse {
    method BUILDALL(|) {
        # traitements initiaux ici

        callsame;   # appelle BUILDALL de la classe mère ou 
                    # BUILDALL par défaut

        # Vérifications finales ici
    }
}

La classe mère Mu, dont héritent toutes les autres classes, fournit une méthode nommée clone qui est quelque peu magique en ce sens qu'elle peut copier des valeurs à partir des attributs privés d'une instance pour créer une nouvelle instance. Cette copie est superficielle, c'est-à-dire qu'elle ne fait que lier les attributs aux valeurs respectives contenues dans l'instance d'origine, elle ne fait pas de copie de ces valeurs contenues.

Nous avons vu un premier exemple de clonage d'une adresse dans la section 3.1.2.

Comme avec new, il est possible de fournir des valeurs initiales pour les attributs publics et, dans ce cas, ces valeurs l'emportent sur celles provenant de l'instance d'origine. Voici l'exemple fourni dans la documentation de la classe Mu.

class Point2D {
    has ($.x, $.y);
    multi method gist(Point2D:D:) {
        "Point($.x, $.y)";
    }
}

my $p = Point2D.new(x => 2, y => 3);

say $p;                     # Point(2, 3)
say $p.clone(y => -5);      # Point(2, -5)

Comme clone n'est pas une subméthode, une classe qui fournit sa propre méthode clone remplacera la méthode clone issue de Mu. Il n'y a pas de mécanisme de type BUILDALL pour le clonage. Par exemple, si l'on désire faire un clone en profondeur pour une classe donnée, il faudrait sans doute appeler callwith ou nextwith pour pousser les copies profondes vers les classes mères :

class A {
    has $.a;
    #...
    method clone {
        nextwith(:a($.a.clone))
    }
}

Ceci fonctionne bien pour les classes simples, mais, dans certains cas, il peut y avoir besoin de suivre le fonctionnement de BUILDALL et de travailler dans l'ordre inverse de MRO :

class B is A {
    has $.b;
    #...
    method clone {
        my $obj = callsame;
        $obj.b = $!b.clone(:seed($obj.a.generate_seed));
        $obj
    }
}

L'application d'un rôle diffère sensiblement de l'héritage d'une classe. Quand un rôle est appliqué à une classe, les méthodes de ce rôle sont copiées dans cette classe. Si plusieurs rôles sont appliqués à la même classe, d'éventuels conflits (par exemple des attributs ou des méthodes non multiples ayant le même nom) entraînent une erreur de compilation. Laquelle peut être résolue en fournissant une méthode ayant le même nom dans la classe en question.

Ce comportement est bien plus fiable que celui de l'héritage multiple, dans lequel les conflits ne sont jamais détectés par le compilateur, mais résolus silencieusement en prenant la méthode de la classe mère qui apparaît en premier dans le MRO - ce qui est, ou non, ce que désirait le développeur.

Par exemple, si vous avez découvert une nouvelle façon de conduire des vaches et essayez de la commercialiser comme une nouvelle forme populaire de transport, vous aurez peut-être une classe Taureau pour les taureaux que vous élevez, et une classe Automobile pour les choses que vous pouvez conduire.

class Taureau {
    has Bool $.castré = False;
    method mène {
        # Mène votre taurillon au vétérinaire pour le châtrer
        $!castré = True;
        return self;
    }
}
class Automobile {
    has $.direction;
    method mène ($!direction) { }
}
class Taurus is Taureau is Automobile { }

my $t = Taurus.new;
$t.mène; # Castre $t

Avec cette configuration, vos pauvres clients seront dans l'incapacité d'utiliser leur Taurus et vous dans celle de vendre vos produits. Il aurait peut-être été plus judicieux d'utiliser des rôles :

role Taurin {
    has Bool $.castré = False;
    method mène {
        # Mène votre taurillon au vétérinaire pour le châtrer
        $!castré = True;
        return self;
    }
}
role Menable {
    has Real $.direction;
    method mène (Real $d = 0) {
        $!direction += $d;
    }
}
class Taurus does Taurin does Menable { }

Ce code va avorter avec un message du genre :

===SORRY!===
Method 'mène' must be resolved by class Taurus because it exists in
multiple roles (Menable, Taurin)

Cette vérification du compilateur vous épargnera, à vous et à vos clients, beaucoup de migraines à rechercher les causes subtiles d'une anomalie. Ici, vous pourriez simplement définir votre classe comme suit :

class Taurus does Taurin does Menable {
    method mène ($direction?) {
        self.Menable::mène($direction)
    }
}
# utilisation:
my $t = Taurus.new;
$t.mène(42.0); # Castre $t

Quand un rôle est appliqué à un second rôle, l'application est retardée et n'a réellement lieu que quand ce second rôle est appliqué à une classe, et les deux rôles sont alors appliqués à la classe. Ainsi :

role R1 {
    # des méthodes ici
}
role R2 does R1 {
    # des méthodes ici
}
class C does R2 { }

produit la même classe C que si on avait écrit :

role R1 {
    # des méthodes ici
}
role R2 {
    # des méthodes ici
}
class C does R1 does R2 { }

Si un rôle contient une méthode bouchon (stub) ou méthode non implémentée, une version non-bouchon d'une méthode ayant le même nom doit être fournie au moment où le rôle est appliqué à une classe, faute de quoi on obtient une erreur à la compilation. Cela permet de créer des rôles qui agissent en tant qu'interfaces abstraites.

role SérialisationAbstraite {
    method sérialise() { ... }  # ... littéraux. Les ... indiquent
                                # que la méthode est abstraite
}

# Ce qui suit donne une erreur de compilation du genre : 
#        Method 'sérialise' must be implemented by Point because
#        it is required by a role
class APoint does SérialisationAbstraite {
    has $.x;
    has $.y;
}

# Mais ceci fonctionne bien :
class SPoint does SérialisationAbstraite {
    has $.x;
    has $.y;
    method sérialise() { "p($.x, $.y)" }
}

La définition de la méthode bouchon peut également être fournie par un autre rôle.

Toute tentative d'instancier un rôle (ainsi que diverses autres opérations sur les rôles) créera automatiquement une classe portant le même nom que le rôle, ce qui permet d'utiliser de façon transparente un rôle comme s'il s'agissait d'une classe :

role Point {
    has $.x;
    has $.y;
    method abs { sqrt($.x * $.x + $.y * $.y) }
}
say Point.new(x => 6, y => 8).abs;

Cette création automatique de classe s'appelle punning et la classe générée est un pun. (Le mot anglais pun désigne un calembour ou un jeu de mots, et punning, c'est faire un jeu de mots ; l'auteur de ces lignes ne voit pas de rapport entre la promotion de rôles au rang de classes et l'idée d'un jeu de mots…).

Comme nous l'avons vu brièvement sous la forme d'un exemple au § 3.3.3.2, il est possible de paramétrer des rôles en leur donnant une signature entre crochets :

role ArbreBinaire[::Type] {
    has ArbreBinaire[Type] $.gauche;
    has ArbreBinaire[Type] $.droite;
    has Type $.noeud;

    method visite-préordre(&cb) {
        cb $.noeud;
        for $.gauche, $.droite -> $branche {
            $branche.visite-préordre(&cb) if defined $branche;
        }
    }
    method visite-postordre(&cb) {
        for $.gauche, $.droite -> $branche {
            $branche.visite-postordre(&cb) if defined $branche;
        }
        cb $.noeud;
    }
    method nouv-de-la-liste(::?CLASS:U: *@el) {
        my $index-milieu = @el.elems div 2;
        my @gauche       = @el[0 .. $index-milieu - 1];
        my $milieu       = @el[$index-milieu];
        my @droite       = @el[$index-milieu + 1 .. *];
        self.new(
            noeud   => $milieu,
            gauche  => @gauche  ?? self.nouv-de-la-liste(@gauche) 
                                !! self,
            droite  => @droite ?? self.nouv-de-la-liste(@droite) 
                               !! self,
        );
    }
}

my $t = ArbreBinaire[Int].nouv-de-la-liste(4, 5, 6);
$t.visite-préordre(&say);    # 5 \n 4 \n 6
$t.visite-postordre(&say);   # 4 \n 6 \n 5

Ici la signature ne comportait qu'une capture de type, mais on peut utiliser des signatures quelconques :

use v6;

enum Gravité <debug info warn erreur critique>;

role Logging[$filehandle = $*ERR] {
    method log( Gravité $sev, $message) {
        $filehandle.print("[{uc $sev}] $message\n");
    }
}

Logging[$*OUT].log(debug, 'On y va');        # [DEBUG] On y va