Archives par étiquette : php

PHP – Le design pattern Etat

Le design pattern Etat est un design pattern comportemental; son utilisation est préconisée dès lors que le comportement d’un objet dépend directement de l’état dans lequel il se trouve à l’instant T.

Programmeur énervé par l'absence de pattern Etat

Programmeur se mettant dans un état pas possible à la lecture d’un code écrit voilà 10 ans

Architecture du design pattern Etat

Les participants à ce design pattern Etat sont au nombre de 3:

  • Une abstraction (interface ou classe abstraite) qui liste les différents comportements devant être implémentés par des états concrets
  • Des états concrets réalisant chacune des méthodes listées dans l’abstraction évoquée ci-dessus
  • Un contexte définissant l’interface que le code client va utiliser et ayant en composition les états concrets auquel il va simplement déléguer les requêtes lui parvenant

Where’s the bill, Bill?

Prenons un exemple parlant: le commerce en ligne ! Une commande faite en ligne traverse toute une série d’états; elle peut être créée, validée, payée ou mise en recouvrement, annulée, remboursée, expédiée etc. Evidemment certaines transitions d’état ne peuvent pas se faire: quand elle est expédiée, elle ne peut pas être annulée et inversement.

Notre site de vente en ligne d’ouvrages informatique CODEBOOKS reçoit plusieurs centaines de commandes par jour.
Une commande est créée dans l’état « En Attente », ce qui signifie qu’elle est en attente d’une validation, manuelle ou automatique. Cette validation peut intervenir ou pas, si le moyen de paiement s’avère frauduleux ou s’il ne parvient pas dans les délais précisés dans les conditions générales de vente.

Une fois qu’elle est validée, elle est préparée puis expédiée afin d’être livrée. C’est notre scénario nominal, le Best Case Scenario.
D’autres scenarii peuvent se produire: l’acheteur réalise à la livraison qu’il a déjà le livre ou bien qu’il l’a commandé dans une langue qu’il ne sait pas lire; il devra être remboursé après renvoi du livre à CODEBOOKS. Une erreur de stock peut également conduire à valider une commande portant sur un livre non disponible, elle devra donc être annulée puis remboursée.

Tes états d’âme, Eric…(air bien connu)

Nos états

Chacun de nos états fera l’objet d’une classe concrète dérivant une classe abstraite (ou implémentant une interface, au choix). J’ai choisi une classe abstraite dans laquelle je factorise mon constructeur, pour éviter de le répéter bêtement dans chaque classe fille car il fait dans tous les cas la même chose. Cette classe abstraite implémente une interface qui va contraindre chacune des classes filles à implémenter l’ensemble des méthodes qu’un état pourra mettre à disposition. Notez bien que le contexte est en composition de chacun des états concrets, pour garder la trace de l’état courant d’une commande.

interface EtatInterface
{
    public function mettreEnAttente(): void;
    public function valider(): void;
    public function annuler(): void;
    public function rembourser(): void;
    public function expedier(): void;
    public function signalerLivre(): void;
}

abstract class EtatAbstract implements EtatInterface
{
    protected $contexte;
    
    public function __construct(ContexteInterface $contexte)
    {
        $this->contexte = $contexte;
    }
}

Après étude, nous avons déterminé les états possibles d’une commande:

  • En Attente: c’est l’état par défaut, celui dans lequel se trouve toute commande « atterrissant » sur notre système d’information
  • Annulé
  • Validé
  • Expédié
  • Remboursé
  • Livré

Vous allez me dire « Mais avec cette interface, l’état Annulé va se retrouver à devoir implémenter une méthode expedier alors qu’il ne doit pas pouvoir transiter vers cet état ! » et vous aurez tout à fait raison ! C’est comme ça, il nous faut une interface qui liste toutes les méthodes qu’on peut invoquer sur l’ensemble des états pour faire plaisir à ce bon vieux Liskov !

Dès qu’une méthode sera appelée sur un état qui ne doit pas l’implémenter, nous lèverons une exception maison nommée MethodNotImplementedException:

class MethodNotImplementedException extends \Exception {}

Le contexte

Notre contexte va être appelé par le code client, c’est lui qui va garder une trace de l’état courant de notre commande. Il a en composition une instance de chacun des différents types d’états disponibles dans lesquels il va s’auto-injecter et à sa construction, il mettra l’état courant à sa valeur par défaut, à savoir « en attente ». Il propose une série de getters (sauf pour enAttente car nous postulons qu’aucun état ne peut effectuer de transition vers cet état initial) ainsi que les méthodes que le code client appellera. Vous notez que ces méthodes font de la délégation bête et méchante. L’unique setter est crucial pour tenir le contexte à jour des changements d’état intervenus dans l’application.

interface ContexteInterface
{
    public function etatValide(): EtatInterface;
    public function etatAnnule(): EtatInterface;
    public function etatExpedie(): EtatInterface;
    public function etatLivre(): EtatInterface;
    public function etatActuel(): EtatInterface;
    public function changerEtat(EtatInterface $etat): void;
}

class Contexte implements ContexteInterface
{
    private $enAttente;
    private $valide;
    private $expedie;
    private $livre;
    private $rembourse;
    private $annule;
    private $etatActuel;

    public function __construct()
    {
        $this->enAttente = new EnAttente($this);
        $this->valide = new Valide($this);
        $this->expedie = new Expedie($this);
        $this->livre = new Livre($this);
        $this->rembourse = new Rembourse($this);
        $this->annule = new Annule($this);
        
        $this->etatActuel = $this->enAttente;
    }
    
    public function etatValide(): EtatInterface
    {
        return $this->valide;
    }
    
    public function etatAnnule(): EtatInterface
    {
        return $this->annule;
    }
    
    public function etatExpedie(): EtatInterface
    {
        return $this->expedie;
    }
    
    public function etatLivre(): EtatInterface
    {
        return $this->livre;
    }
    
    public function etatRembourse(): EtatInterface
    {
        return $this->rembourse;
    }
    
    public function etatActuel(): EtatInterface
    {
        return $this->etatActuel;
    }
    
    public function changerEtat(EtatInterface $etat): void
    {
        $this->etatActuel = $etat;
    }
    
    public function valider(): void
    {
        $this->etatActuel->valider();
    }
    
    public function expedier(): void
    {
        $this->etatActuel->expedier();
    }
    
    public function signalerCommeLivre(): void
    {
        $this->etatActuel->signalerLivre();
    }
    
    public function effectuerRemboursement(): void
    {
        $this->etatActuel->rembourser();
    }
    
    public function effectuerAnnulation(): void
    {
        $this->etatActuel->annuler();
    }
}

Nos états…concrets !

EnAttente

Prenons notre première classe concrète: EnAttente. Cet état peut effectuer des transitions vers les états Validé (si le paiement est valide) ou Annulé (dans le cas contraire). Il ne peut pas le faire vers lui-même ainsi que vers les états Remboursé, Expédié et Livré car à ce stade le paiement de la commande n’est pas une certitude.

class EnAttente extends EtatAbstract
{   
    public function mettreEnAttente(): void
    {
        throw new MethodNotImplementedException('Déjà en attente');
    }
    
    public function valider(): void
    {
        $this->contexte->changerEtat($this->contexte->etatValide());
    }
    
    public function annuler(): void
    {
        $this->contexte->changerEtat($this->contexte->etatAnnule());
    }
    
    public function rembourser(): void
    {
        throw new MethodNotImplementedException('En attente');
    }
    
    public function expedier(): void
    {
        throw new MethodNotImplementedException('En attente');
    }
    
    public function signalerLivre(): void
    {
        throw new MethodNotImplementedException('En attente');
    }
}

Annulé

Comme tous les états, Annule ne peut aller vers lui-même et il n’effectue de transition qu’en direction de Remboursé.

class Annule extends EtatAbstract
{
    public function mettreEnAttente(): void
    {
        throw new MethodNotImplementedException('Annulé');
    }
    
    public function valider(): void
    {
        throw new MethodNotImplementedException('Annulé');
    }
    
    public function annuler(): void
    {
        throw new MethodNotImplementedException('Déjà annulé');
    }
    
    public function rembourser(): void
    {
        $this->contexte->changerEtat($this->contexte->etatRembourse());
    }
    
    public function expedier(): void
    {
        throw new MethodNotImplementedException('Annulé');
    }
    
    public function signalerLivre(): void
    {
        throw new MethodNotImplementedException('Annulé');
    }
}

Validé

Valide peut évoluer en Annulé (opposition bancaire ou autres) ou en Expédié, si tout se déroule normalement.

class Valide extends EtatAbstract
{    
    public function mettreEnAttente(): void
    {
        throw new MethodNotImplementedException('Validé');
    }
    
    public function valider(): void
    {
        throw new MethodNotImplementedException('Déjà validé');
    }
    
    public function annuler(): void
    {
        $this->contexte->changerEtat($this->contexte->etatAnnule());
    }
    
    public function rembourser(): void
    {
        throw new MethodNotImplementedException('Validé');
    }
    
    public function expedier(): void
    {
        $this->contexte->changerEtat($this->contexte->etatExpedie());
    }
    
    public function signalerLivre(): void
    {
        throw new MethodNotImplementedException('Validé');
    }
}

Expedié

Cet état peut effectuer des transitions uniquement vers Livré.

class Expedie extends EtatAbstract
{   
    public function mettreEnAttente(): void
    {
        throw new MethodNotImplementedException('Expédié');
    }
    
    public function valider(): void
    {
        throw new MethodNotImplementedException('Expédié');
    }
    
    public function annuler(): void
    {
        throw new MethodNotImplementedException('Expédié');
    }
    
    public function rembourser(): void
    {
        throw new MethodNotImplementedException('Expédié');
    }
    
    public function expedier(): void
    {
        throw new MethodNotImplementedException('Déjà expédié');
    }
    
    public function signalerLivre(): void
    {
        $this->contexte->changerEtat($this->contexte->etatLivre());
    }
}

Remboursé

C’est un état terminal.

class Rembourse extends EtatAbstract
{
    public function mettreEnAttente(): void
    {
        throw new MethodNotImplementedException('Remboursé');
    }
    
    public function valider(): void
    {
        throw new MethodNotImplementedException('Remboursé');
    }
    
    public function annuler(): void
    {
        throw new MethodNotImplementedException('Remboursé');
    }
    
    public function rembourser(): void
    {
        throw new MethodNotImplementedException('Déjà Remboursé');
    }
    
    public function expedier(): void
    {
        throw new MethodNotImplementedException('Remboursé');
    }
    
    public function signalerLivre(): void
    {
        throw new MethodNotImplementedException('Remboursé');
    }
}

Livré

Cet état ne peut transiter que vers Annulé, quand le client reçoit un produit qui ne lui convient pas. L’annulation donnera ensuite lieu à un remboursement.

class Livre extends EtatAbstract
{
    public function mettreEnAttente(): void
    {
        throw new MethodNotImplementedException('Livré');
    }
    
    public function valider(): void
    {
        throw new MethodNotImplementedException('Livré');
    }
    
    public function annuler(): void
    {
        $this->contexte->changerEtat($this->contexte->etatAnnule());
    }
    
    public function rembourser(): void
    {
        throw new MethodNotImplementedException('Livré');
    }
    
    public function expedier(): void
    {
        throw new MethodNotImplementedException('Livré');
    }
    
    public function signalerLivre(): void
    {
        throw new MethodNotImplementedException('Déjà Livré');
    }
}

Le code client

Nous avons à notre disposition une classe Commande; elle possède une référence vers le contexte, qui va ainsi garder trace des différents états qu’elle traverse. C’est elle que notre code client va appeler.

class Commande
{
    private $contexte;
    
    public function __construct(ContexteInterface $contexte)
    {
        $this->contexte = $contexte;
    }
    
    public function valider(): void
    {
        $this->contexte->valider();
        echo "Etat = ".get_class($this->contexte->etatActuel()).PHP_EOL;
    }

    public function expedier(): void
    {
        $this->contexte->expedier();
        echo "Etat = ".get_class($this->contexte->etatActuel()).PHP_EOL;
    }
    
    public function signalerCommeEtantLivre(): void
    {
        $this->contexte->signalerCommeLivre();
        echo "Etat = ".get_class($this->contexte->etatActuel()).PHP_EOL;
    }
    
    public function procederAuRemboursement(): void
    {
        $this->contexte->effectuerRemboursement();
        echo "Etat = ".get_class($this->contexte->etatActuel()).PHP_EOL;
    }
 
    public function effectuerUneAnnulation(): void
    {
        $this->contexte->effectuerAnnulation();
        echo "Etat = ".get_class($this->contexte->etatActuel()).PHP_EOL;
    }
    
}

$contexte = new Contexte();
$commande = new Commande($contexte);

Voici notre scénario nominal, ou best case scenario (fingaz crossed!) :

$commande->valider();
$commande->expedier();
$commande->signalerCommeEtantLivre();

La commande va traverser 4 états: elle va passer de « en attente » à « validée », puis à « expédiée » et enfin à « livrée ».

Voici le scénario où la commande est validée mais une erreur de stock conduit à devoir l’annuler et la rembourser:

$commande->valider();
$commande->effectuerUneAnnulation();
$commande->procederAuRemboursement(); // état TERMINAL

Dans le scénario suivant, le produit est livré mais l’acheteur réalise qu’il l’a déjà ou bien qu’il s’est trompé lors de sa commande et le produit de remplacement n’est plus disponible dans le stock:

$commande->valider();
$commande->expedier();
$commande->signalerCommeEtantLivre();
$commande->effectuerUneAnnulation();
$commande->procederAuRemboursement(); // état TERMINAL

Enfin, dans notre dernier scénario, le paiement n’est pas arrivé à temps (mandat, virement bancaire, chèque…) et il faut annuler la commande ! C’est le plus simple:

$commande->effectuerUneAnnulation();

Le design pattern Prototype en PHP

Prototype est un design pattern de création: son but est de répliquer des instances dites « prototypes » via un mécanisme de clonage.
Il est prescrit lorsqu’il convient d’éviter de trop nombreuses instanciations d’une classe, notamment lorsque celle-ci possède une logique assez complexe dans son constructeur, ce qui idéalement ne devrait jamais arriver.

Il est important d’économiser les ressources car le coût d’un clonage d’objet reste bien inférieur à celui d’une instanciation. Evidemment, vous ne verrez pas la différence si vous travaillez avec une dizaine d’objets mais ce ne sera sans doute pas le cas si votre application doit gérer 100 000 objets simultanément le jour d’une facturation par exemple.

prototype de voiture

Protype attendant un clonage incognito

Les composants de Protoype

  • une abstraction (classe abstraite ou interface) qui force la présence d’une méthode dédiée au clonage dans les classes concrètes
  • une ou plusieurs classes concrètes dériveront l’abstraction, implémentant de fait la méthode de clonage. Les instanciations seront faites sur ces classes
  • des clones de ces classes seront effectués par le code client, qui participe à ce pattern

Voici notre abstraction; elle force l’implémentation d’une méthode __clone() et par chance, PHP en fourni une « out of the box » comme on dit (oui, on peut aussi dire « nativement ») ! Le reste est très basique: un constructeur sans aucune logique métier, qui prend ce qu’on lui donne et le range consciencieusement, un setter et deux getters.

L’abstraction

abstract class HumainAbstract
{   
    protected $prenom;
    
    protected $sexe;
        
    public function __construct(string $prenom)
    {
        $this->prenom = $prenom;
    }
    
    public function donnerSexe(): string
    {
        return $this->sexe; 
    }
    
    public function changerPrenom(string $prenom)
    {
        $this->prenom = $prenom;
    }
    
    public function donnerPrenom(): string
    {
        return $this->prenom; 
    }
    
    abstract public function __clone();
}

Les classes concrètes

Les classes concrètes – les prototypes – vont dériver cette classe abstraite et, pour rester simples, ne feront absolument rien dans leur méthode __clone() ! Elles ont une variable d’instance qu’il est juste possible de lire mais pas de modifier. Seul le prénom est modifiable (regardez dans la classe abstraite !).

class Male extends HumainAbstract
{
    protected $sexe = 'M';

    public function __clone()
    {
    }
}

class Femelle extends HumainAbstract
{
    protected $sexe = 'F';
    
    public function __clone()
    {
    }
}

Le code client

Le client est un acteur à part entière du design pattern prototype, c’est lui qui va cloner les prototypes.
Ici nous décidons que, les premiers humains ayant sans doute communiqué entre eux par un langage très primitif, notre prototype de mâle s’appellera « Rrrnnngrrwggl », tandis que la femelle portera le doux sobriquet de « Nyyyynyaaa ».

Tous les êtres humains descendant de ces respectables parents à la pilosité prononcée ne seront que des clones dont nous changerons uniquement le prénom. Vous noterez que nous utilisons l’affectation dynamique, c’est à dire que chaque clone sera rangé dans une variable dont le nom sera incrémenté à chaque itération de notre boucle.

$prenoms = [
        'René', 'Eric', 'Jean', 'Robert', 'Marius',
        'Kevin', 'Léo', 'Jacques', 'Loïc', 'John',
        'Alexis', 'Kenneth', 'Nathanaël', 'Christophe'
    ];
    
$male1 = new Male('Rrrnnngrrwggl');

$numeroClone = 0;
$clones = [];

foreach ($prenoms as $prenom) {
    ++$numeroClone;
    
    $nomClone = 'clone'.$numeroClone;
    $$nomClone = clone $male1;
    $$nomClone->changerPrenom($prenom);
    $clones[] = $$nomClone;
}

$prenoms = [
        'Lise', 'Marie', 'Ninon', 'Rachida', 'Ana',
        'Martine', 'Svetlana', 'Eve', 'Carole',
        'Sylvie', 'Laurie', 'Zhang', 'Fatoumata'
    ];

$femelle1 = new Femelle('Nyyyynyaaa');
    
foreach ($prenoms as $prenom) {
    ++$numeroClone;
    
    $nomClone = 'clone'.$numeroClone;
    $$nomClone = clone $femelle1;
    $$nomClone->changerPrenom($prenom);
    $clones[] = $$nomClone;
}

foreach ($clones as $clone) {
    echo $clone->donnerSexe().'/'.$clone->donnerPrenom().PHP_EOL;
}

A retenir

  • N’implémentez pas Prototype si vous devez gérer un petit nombre de copies, ce serait tuer une mouche au lance-roquettes
  • Lors d’un appel à __clone(), le constructeur n’est pas appelé (c’est le but)
  • Si votre objet à cloner a des objets en compositions, pensez à les cloner eux aussi pour éviter de pointer vers une référence qui n’est pas la bonne…
  • Prenez garde aux références circulaires (A dépend de B qui dépend de C qui dépend de A…) entre les objets

PHP 7 : le typage strict

Une des grandes forces de PHP – qui est aussi, hélas !, une de ses plus grandes faiblesses – est l’absence de typage fort comme c’est le cas en Java, en C#, C++ ou dans bien d’autres langages dits « orientés objet ». PHP s’occupe de faire les conversions de type qui l’arrangent, notamment lorsque l’on effectue des comparaisons entre des types différents (voilà pourquoi les opérateurs stricts ont été introduits qui comparent en valeur et surtout en type). Tout ça est décidé de façon dynamique au runtime (à l’exécution, en bon français) et non pas de façon statique, à la compilation.

Une nouveauté qui fait des heureuses !

Une nouveauté qui fait des heureuses !

Depuis les versions 5.X, on pouvait déjà typer des paramètres de fonction avec certains types non-scalaires : objet depuis 5.0 et array depuis 5.1 (et callable par la suite, mais passons…). Dans des temps reculés (avant 5.X), on n’avait pas trop le choix:
function peuimporte ($param, $reparam) {
var_dump($param);
var_dump($reparam);
}

L’appel de cette fonction pouvait se faire avec des arguments de divers types : entiers, flottants, tableaux, objets, chaînes de caractères…Pour faire court, on pouvait un peu passer tout et (surtout) n’importe quoi !

peuimporte (1, 1.23);
peuimporte ("a", 1);
peuimporte (array(), new StdClass());

Un type scalaire est un type qui ne contient qu’une valeur à la fois: un entier, une chaine de caractères, un booléen etc. Un type non scalaire peut contenir plusieurs valeurs; un tableau, un objet…ce sont des types composites – ou des collections de valeurs.

Depuis PHP 5.1 disais-je, on pouvait forcer le typage des paramètres des fonctions avec des types non scalaires comme un tableau:


function peuimporte (Array $param) {
// faites ce que bon vous semble
}

ou bien un objet d’un type particulier:


class UnTypeAuPif {}
function peuimporte (UnTypeAuPif $param) {
// faites ce que bon vous semble
}

ou encore d’un super-type, comme une interface:


interface Bidon {}
class UnTypeAuPif implements Bidon {}
class UnAutreTypeAuPif implements Bidon {}
function peuimporte (Bidon $param) {
// faites ce que bon vous semble
}

Il suffit alors de passer en argument une instance qui ne se conforme pas aux spécifications que constitue la signature de notre fonction et VLAN!


Catchable fatal error: Argument 1 passed to peuimporte() must be an instance of UnTypeAuPif, instance of stdClass given

Ici j’ai tenté de réaliser l’invocation suivante :
peuimporte(new StdClass);

J’ai allégrement violé le contrat qui me lie à cette fonction et qui stipule qu’il ne faut passer que des instances de UnTypeAuPif (dans le premier exemple).

Depuis mars 2015 (et une RFC qui a fait l’objet d’un débat, puis d’un vote) il est donc prévu que PHP 7 nous donne la possibilité de spécifier des types scalaires pour nos arguments…ENFIN ! Il deviendra donc possible d’écrire:


function peuimporte (int $param) {
// faites ce que bon vous semble
}

ou bien:


function peuimporte (string $param) {
// faites ce que bon vous semble
}

ou encore:


function peuimporte (float $param) {
// faites ce que bon vous semble
}

Le fait de passer en argument d’un appel une variable du mauvais type provoque une erreur fatale, par exemple:


Fatal error: Uncaught TypeError: Argument 1 passed to peuimporte() must be of the type float, string given

Pour activer ce typage strict sous PHP 7, il faut utiliser declare que l’on connait depuis 5.3 et qui sert lors de la compilation du fichier. Ce language construct sera placé en tout début de fichier (sous peine de provoquer une erreur fatale)  comme suit:


declare(strict_types = 1);
function peuimporte (float $param) {
// TODO
}
peuimporte(1.23);

Notez que le mode bloc, originellement proposé pour strict_types , a été interdit dans PHP 7. Cette fonctionnalité n’est pas forcée par défaut, nul risque donc de BC break dans le code existant. L’aspect lâche du typage en PHP reste encore la règle (pour combien de temps ?), ce qui continuera de faciliter l’intégration des gens qui ne sont pas des développeurs de formation.

Pour les développeurs qui viennent du monde des langages fortement typés et qui se sentent frustrés par le typage faible de PHP, c’est une bonne nouvelle et sans doute une raison de plus de cesser de prendre PHP pour un langage de seconde zone.

Il me tarde que PHP 7 fasse l’objet d’une release officielle pour bénéficier de cette tant attendue fonctionnalité !

Testé avec un PHP7 bêta compilé sur Debian Jessie…et approuvé !

Les tests unitaires dans Eclipse PDT avec MakeGood

MakeGood est un plug-in pour Eclipse qui vous permettra de lancer de manière continue (à l’issue d’une simple modification du code) vos tests unitaires. Rien de plus énervant que de devoir alterner entre ligne de commande et IDE pour développer, n’est-ce pas ? Ce plug-in, développé par une entreprise japonaise, est là pour mettre un terme à vos souffrances de développeur PHP consciencieux ! Voyons sans plus tarder comment il s’installe. Je suppose évidemment que vous respectez les pré-requis, à savoir une installation fonctionnelle d’Eclipse PDT, de phpUnit (via PEAR) et de XDebug.

Télécharger et installer le plug-in

Cliquez sur Aide / Installer de nouveaux logiciels

1

Voici la fenêtre qui apparaît à l’écran :

1-bis

Créez un nouveau dépôt pour récupérer les sources du plug-in

Cliquez sur le bouton « Ajouter » (« Add ») et renseignez les champs comme suit :

2

Sélectionnez le paquetage cible

3

Une fois le plug-in installé et Eclipse PDT relancé pour prendre en compte ce nouvel ajout, il va nous falloir paramétrer un projet !

Créer un projet intégrant MakeGood

Créons tout d’abord un projet PHP « local », c’est à dire hébergé sur votre machine. Vous devez avoir un exécutable PHP préalablement installé (PHP cli).

4

Donnons lui un nom trivial, c’est un simple essai, ne cherchons pas les complications inutiles !

5

Voilà maintenant votre projet déployé dans l’explorateur :

6

Ouvrons la vue dédiée à MakeGood :

7

Vous voyez un message d’erreur s’afficher dans cette vue : « MakeGood is not configured yet. Fix… », c’est le signe qu’il nous reste du paramétrage à faire !

8

Paramétrer votre projet PHP pour utiliser MakeGood

L’exécutable PHP

MakeGood aura besoin de localiser votre exécutable PHP, celui que vous utilisez en ligne de commande. Ouvrez donc les préférences générales d’Eclipse PDT :

9

Déployez le noeud intitulé « PHP » et rendez-vous à la sous-section « PHP Executables ». Notez au passage la section sur MakeGood en haut de l’image.

10

Cliquez sur « Add » (« Ajouter ») pour y paramétrer votre executable PHP. A titre d’exemple, voici le mien tel qu’il est configuré sur ma machine GNU/Linux Debian (c’est pourquoi la fenêtre signale « Edit » et pas « Add »).

11

Voici la raison pour laquelle vous devez avoir un PHP Cli installé sur votre machine, c’est une condition sine qua non pour que MakeGood fonctionne, mais ce n’est pas la seule ! Rendez-vous à présent sur le noeud « Debug » de vos préférences PHP :

12

Voici mes paramétrages : nous avons paramétré notre exécutable PHP, autant nous en servir en y faisant référence !

13

PEAR

Il va falloir faire mention de PEAR dans les librairies que devra prendre en charge Eclipse PDT. Pour ce faire, dans les préférences générales de votre IDE, vous vous rendrez à la section « PHP Librairies » :

14

Cliquez sur Nouveau et donnez un nom à votre librairie PEAR…comme PEAR par exemple ! 😉
Une fois que votre librairie apparaît dans la liste, sélectionnez-la et cliquez sur le bouton « Add external folder » pour faire référence au répertoire qui héberge votre installation de PEAR (la racine de tous vos extensions PEAR si vous préférez…), une fois ceci fait, vous devriez avoir quelque chose qui ressemble à peu près à ça à l’écran :

15

Reste à faire mention de votre librairie PEAR cette fois-ci dans les propriétés de votre projet et non plus d’Eclipse PDT. Sélectionnez votre projet dans l’explorateur et sélectionnez les propriétés avec un clic droit.

16

Votre cible est la rubrique « PHP Include Path » où vous allez renseigner la librairie PEAR créée un peu plus haut, mais au niveau Eclipse et pas projet. Cliquez sur « Add Library » ou son équivalent français et sélectionnez ensuite votre bibliothèque PEAR.

17

18

Voici venu le moment de créer un répertoire destiné à contenir nos tests unitaires, faisons preuve d’une imagination sans limites et nommons le « Tests ».
19

20

Toujours dans les propriétés du projet (clic droit ou bien Alt+Entrée, une fois ce projet sélectionné dans l’explorateur), rendez vous dans la partie dédiée à MakeGood et cliquez sur « Add » dans l’onglet « General » pour ajouter votre joli répertoire de test nouvellement créé !

21

22

Désormais, le message d’erreur rouge qui apparaissait tout à l’heure a laissé place à la mention « Waiting a for test run… » dans la vue MakeGood et vous êtes prêt(e) à vous lancer dans le test unitaire :

23

Créer des tests unitaires simples

Notre classe à tester

Créer un fichier PHP à la racine de « MonSuperProjet », nommez le Calculette.php. Dans votre répertoire Tests, créez un fichier PHP nommé « CalculetteTest.php ». Respectez le nommage, dicté par les bonnes pratiques.

24

Vous avez peut-être remarqué ce faisant que, et même si c’est allé très vite, quelque chose s’est passé alors même que vous avez crée ce fichier CalculetteTest.php dans le répertoire Tests…le statut de MakeGood a changé, il a tenté de lancer vos tests mais comme votre fichier est vide, il affiche « Running a test… » avec 0 tests indiqués.

Calculette.php

Ce fichier de test est très librement adapté de l’exemple de la documentation officielle de phpUnit, qu’évidemment je vous encourage à aller voir en ligne ! Voici son contenu :

class Calculette {
    public function RacineCarree($nombre) {

        if (0 > $nombre) {
	    throw new InvalidArgumentException('Le nombre fourni est négatif');
	}

	return sqrt($nombre);
    }
}

CalculetteTest.php

Notre classe de test aura, quant à elle, cette allure là :


require_once 'Calculette.php';

class CalculetteTest extends PHPUnit_Framework_Testcase
{
    protected $_calculette;

    public function setUp() {
	$this->_calculette = new Calculette;
    }

    public function testRacineCarreeNegative() {
	$this->setExpectedException('InvalidArgumentException');
	$this->_calculette->RacineCarree(-1);
    }

    public function testRacineCarreePositive() {
	$this->assertEquals(3, $this->_calculette->RacineCarree(9));
    }
}

N’hésitez pas à ajouter des méthodes dans la classe à tester et évidemment à les tester dans CalculetteTest.php, vous verrez qu’à chaque Ctrl+S dans votre code (dans Calculette.php comme dans CalculetteTest.php), les tests vont se relancer, c’est ça l’idée du « Continuous Test Runner » que se veut être MakeGood. Comme nos tests sont bien écrits, c’est du vert que nous avons; les deux passent !

26

N’oubliez pas d’être curieux(se) et d’aller inspecter les temps d’exécution des tests, vous aurez parfois des surprises !
27

A vous de jouer maintenant !

PHP : quelques code smells

Cette expression code smell a été inventée par Kent Beck et elle est apparue pour la première fois dans le livre « Refactoring: Improving the Design of Existing » de Martin Fowler; signifiant littéralement « odeurs de code », cette expression peut être vue comme matérialisant une « piste olfactive » qui vous indique – à vous, fins limiers du code – que quelque chose ne va pas dans des développements (les vôtres ou des développements hérités – legacy). Voici quelques unes de ces « odeurs » que l’on rencontre le plus fréquemment; j’ai parfois utilisé des noms « officiels » tout comme des noms que j’emploie personnellement pour les désigner au quotidien.

Les commentaires : les commentaires expliquent brièvement ce qui se passe dans le code. Pour reprendre l’adage populaire : « Trop de commentaire tue le commentaire », soyez concis, ne détaillez pas le code trop finement, sinon vous paraphrasez !

Le code dupliqué : il indique un mauvais design. C’est un signe qu’il est temps de refactorer.

La forêt de « if » : si vous noyez votre code dans une jungle de branchements conditionnels, c’est que vous faites fausse route. Refactorez là encore en utilisant des designs patterns tels que Strategy, par exemple.

La « monstro-classe » : typique du mauvais design, du non respect des principes SOLID et en particulier du premier, dit de la Single Responsibility. Ces classes font tout, le café, le service, le parking…Un jour ou l’autre vous pairez cher ces 3000 lignes d’inepties.

La syllogomanie : on conserve du code mort dans de gros pavés de commentaires…sans savoir pourquoi… »au cas où ». Et les systèmes de gestion de version, ça sert à quoi ?

La foire aux variables d’instances : on en crée plein, pour y stocker des valeurs qui ne servent que temporairement à l’objet, qui du coup enfle et enfle et enfle.

La classe fantôme : elle n’a pas vraiment d’utilité, de raison d’être, elle ne fait rien de significatif ou bien délègue l’intégralité de ses tâches. Elle doit être impitoyablement éliminée du design.

Le nommage inapproprié : s’applique aux variables ou aux méthodes; des exemples vu dans les entreprises pour lesquelles j’ai travaillé : des méthodes nommées « find2 », « find3 » et qui faisaient presque la même chose que la méthode originelle « find » (et les Design Patterns, ça sert à quoi ?), des variables nommées $jb, du nom de leur créateur, ou $a, $b, $o, des méthodes avec des noms horriblement longs et ridicules, comme « faitCeQuilFautPourLeTac() » (tout ça est vrai, je n’invente rien !).

L’absence de typage : PHP est faiblement typé comme vous le savez, mais vous pouvez au moins typer les paramètres d’appel des fonctions (objets/interfaces/tableaux). Usez en et abusez en pour verrouiller votre conception objet et ne pas permettre tout et n’importe quoi !

Pour aller plus loin :

Smells to refactoring (PHP, anglais)

Comment écrire du code inmaintenable (anglais)

Code smells (anglais)

smell

Image empruntée au site Rin’s treasure

PHP : un exemple simple du design pattern Template Method

Vous cherchiez un design pattern facile à aborder ? Le design pattern template method est celui qu’il vous faut ! Son principe est très simple : dans une classe, une méthode dite template est composée de sous-méthodes dont on sait que chaque sous-classe l’implémentera à sa manière. Ces sous-méthodes sont généralement en type d’accès protégé car invoquées uniquement par cette fameuse méthode template; l’extérieur n’a pas à connaître les mystères de votre implémentation (encapsulation, vous dîtes ?). Bien entendu, étant donné que chaque classe fille implémentera ces méthodes comme bon lui semble, il convient de les signifier comme abstraites dans la classe mère.

Imaginons une classe TunnelCommande qui expose une méthode template nommée finaliserCommande; cette méthode décrit un algorithme en spécifiant ce qui devra être fait par ses sous-classes et dans quel ordre. Cette classe comporte la méthode payePort dite « adaptateur » (hook) qui peut être réécrite dans les classes filles. Elle sert à conditionner une partie du flot d’exécution de l’algorithme de la méthode template. Son utilité dans notre cas est de permettre à un certain type d’utilisateur de s’affranchir du paiement des frais de port.

abstract class TunnelCommande
{
    public function finaliserCommande(): void
    {
        $this->faireTotal();
        
        if ($this->payePort()) {
            $this->ajouterFraisPort();
        }

        $this->rediriger('page_paiement');
    }

    public function payePort(): bool
    {
    	return true;
    }

    public function rediriger(string $template): void
    {
    	echo "Redirection vers ", $template, PHP_EOL;
    }

    abstract protected function faireTotal(): void;
    abstract protected function ajouterFraisPort(): void;
}

Nous avons deux classes concrètes qui dérivent TunnelCommande et implémentent les méthodes abstraites en leur donnant un comportement spécifique. Dans CommandePremium, la méthode ajouterFraisPort qui est imposée par la classe mère abstraite ne fait rien, payePort renvoyant false elle ne sera de toutes façons jamais invoquée dans ce scénario là.


class CommandeClient extends TunnelCommande
{
    protected function faireTotal(): void
    {
        echo "Je fais le total", PHP_EOL;
    }

    protected function ajouterFraisPort(): void 
    {
        echo "J'applique les frais de port du client normal", PHP_EOL;
    }
}

class CommandePremium extends TunnelCommande
{
    protected function faireTotal(): void
    {
        echo "Appliquer 5% de rabais pour les clients Premium", PHP_EOL;
    }

    protected function ajouterFraisPort(): void
    {
        return;
    }

    public function payePort(): bool
    {
    	return false;
    }
}

$premium = new CommandePremium;
$premium->finaliserCommande();

$standard = new CommandeClient;
$standard->finaliserCommande();

Dans ce design pattern, tout le travail est fait dans la classe mère, abstraite. Quand je dis « tout le travail », je parle de la structure générale de l’algorithme, de l’ordre des opérations. Evidemment, la responsabilité de l’implémentation des détails de cet algorithme « général » est déléguée aux classes dérivées, via le mécanisme d’abstraction.

PHP : héritage multiple des interfaces

Vous le savez sûrement, les interfaces servent à contraindre des classes à implémenter une ou des méthodes publiques. N’importe quelle classe, abstraite ou concrète, peut les implémenter. Mais saviez-vous que, contrairement aux classes, les interfaces peuvent hériter de plusieurs parents ?

Prenons l’exemple suivant ;


interface Counterializable extends Serializable, Countable {
    public function counterialiser();
}

class CompteEtSerialise implements Counterializable {}

Ici, l’interface Counterializable (contraction de Countable et de Serializable) impose à notre classe concrète CompteEtSerialise l’implémentation de 4 méthodes:
– deux provenant de Serializable (serialize et unserialize)
– une provenant de Countable (count)
– une provenant de Counterializable (counterialiser)

Si l’on exécute ce code, il se produit l’erreur suivante :

PHP Fatal error: Class CompteEtSerialise contains 4 abstract methods
and must therefore be declared abstract or implement the remaining
methods (Counterializable::counterialiser, Serializable::serialize,
Serializable::unserialize, ...)

Ce message d’erreur est bien la preuve que l’héritage multiple, qui ne s’applique pas aux classes, s’applique en revanche aux interfaces !