Chapitre 1 : Les Design Patterns

Introduction
Les Design patterns représentent les meilleures pratiques utilisées par les développeurs de
logiciels orientés objet. Les design patterns sont des solutions aux problèmes généraux
rencontrés par les développeurs lors du développement de logiciels. Ces solutions ont été
obtenues par essais et erreurs par de nombreux développeurs sur une période assez longue.
Un design pattern n’est pas une conception finie qui peut être transformée directement en code.
Il s’agit d’une description ou d’un modèle pour résoudre un problème qui peut être utilisé dans
de nombreuses situations différentes.

Types de Design Patterns

Il existe 23 design patterns qui peuvent être classés en trois catégories: modèles de création
(creational patterns), modèles de structuration (structural patterns), modèles de comportement
(behavioral patterns)

Creational
Utilisatioin pour construire des objets de manière a ce qu’ils puissent etre decouplé de leur
systemen d’implementation

 Singleton

 Factory

 Builder

 Prototype

 Pool

Structural patterns
Ces design patterns concernent la composition des classes et des objets. Le concept d’héritage
est utilisé pour composer des interfaces et définir des façons de composer des objets pour
obtenir de nouvelles fonctionnalités.
 Adapter / Wrapper

 Dependency Injection
 Decorator

 Facade

 Composite

 Proxy

 Bridge

 Data Mapper

 Fluent Interface

 Flyweight

 Registry

Behavioral patterns
Ces design patterns concernent spécifiquement la communication entre les objets.
 Iterator

 Observer

 Memento

I Pourquoi utiliser les design patterns ? II Les types de design patterns

➢ De création

Nous utilisons le design patterns singleton afin de limiter le nombre d’instances pouvant être
créées à partir d’une classe consommatrice.

L’anatomie du pattern singleton

Commençons par comprendre les caractéristiques structurelles d’une classe qui suit le pattern
singleton:

 Un constructeur privé est utilisé pour empêcher la création directe d’objets à partir de la classe.

 Le processus est effectué au sein du constructeur privé.

 La seule façon de créer une instance à partir de la classe est d’utiliser une méthode statique qui

crée l’objet uniquement s’il n’a pas déjà été créé.

<?php

class Singleton {

// Gardez l'instance de classe.

private static $instance = null;

// Le constructeur est privé pour empêcher l'initiation. private function __construct()

// Mettez le processus de traitement ici.

/* L'objet est créé à partir de la classe elle-même uniquement si la classe n'a pas d'instance.

*/ public static function getInstance()

if (self::$instance == null)

{ self::$instance = new Singleton();

} return self::$instance;

?>

Comme nous limitons le nombre d’objets pouvant être créés à partir d’une classe à un seul,
 nous nous retrouvons avec toutes les variables pointant vers le même objet unique.

<?php

// Toutes les variables pointent vers le même objet.

$obj1 = Singleton::getInstance();

$obj2 = Singleton::getInstance(); $obj3 = Singleton::getInstance();

?>

Exemple pratique: Connexion à une base de données

Regardons un exemple du pattern singleton avec une classe qui établit une connexion à une
base de données et limite le nombre d’instances à une seule.

<?php

// Singleton pour connecter au bd.

class ConnexionBD {

// Gardez l'instance de classe. private static $instance = null; private $conn;

// La connexion au bd est établie dans le constructeur privé. private function __construct()

$this->conn = new PDO("mysql:host=localhost; dbname=test", "myuser", "mypassword");

}
 public static function getInstance()

if(!self::$instance)

self::$instance = new ConnexionBD();

return self::$instance;

public function getConnection()

return $this->conn;

?>

Puisque nous utilisons une classe qui vérifie si une connexion existe déjà avant d’en établir
une nouvelle, peu importe le nombre de fois où nous créons un nouvel objet à partir de la
classe, nous obtenons toujours la même connexion.

<?php

$instance = ConnexionBD::getInstance();

$conn = $instance->getCon nection();

var_dump($conn);
 $instance = ConnexionBD::getInstance();

$conn = $instance->getConnection();

var_dump($conn);

?>

Le résultat est la même connexion pour les deux instances.

Design Patterns: Builder en PHP

Builder est une interface qui crée des parties d’un objet complexe.
Le pattern Builder est un pattern bien connu dans le monde PHP. Il est particulièrement utile
lorsque vous devez créer un objet avec de nombreuses options de configuration possibles.

Builder se compose de:

 Classe concrète
 Une interface builder

 Les différentes implémentations de l’interface builder

 Une classe directeur qui appelle le builder approprié et le renvoie.

Classe concrète (Car)

<?php class Car

public $name;

public $model;

public function __construct(){}

?>

Interface builder
<?php interface CarBuilderInterface

{ public function setName();

public function setModel();

public function getCar();

?>

Comme indiqué dans le code ci-dessus, l’interface du builder contient des méthodes
pour préparer le builder lors de sa création et la méthode getCar() retournera l’objet final.

Implémentations de l’interface builder

<?php

class BmwCarBuilder implements CarBuilderInterface

private $car;

public function __construct(Car $car)

$this->car = $car;

} public function setName()

$this->car->name = "Bmw";

public function setModel()

$this->car->model = "X90";

} public function getCar()

{
 }

?>

Comme vous le voyez ci-dessus, nous venons de créer quelques implémentations de l’interface
Builder en passant la classe concrète d’origine dans chaque constructeur, puis nous avons
implémenté les setters telles que setName et setModel qui à leur tour fourniront un objet
complet qualifié, enfin nous avons appelé getCar() pour retourner l’objet Car.

La classe directeur
Maintenant, la dernière chose est la classe directeur, la principale responsabilité du directeur
est d’obtenir une interface builder et d’appeler les méthodes de l’interface builder puis de
récupérer l’objet.

<?php

class CarDirector

{ public function build(CarBuilderInterface $builder)

$builder->setName();

$builder->setModel();

return $builder->getCar();

?>

Maintenant, pour utiliser le builder:

<?php
 $director = new VehicleDirector();

$audi = $director->build(new AudiCarBuilder(new Car()));

$bmw = $director->build(new BmwCarBuilder(new Car()));

echo "Modél: " . $audi->name . "<br>";

echo "Modél: " . $audi->model . "<br>";

var_dump($audi);

?>

Structurels
➢ Le MVC

Contexte
CRITIQUE DES MODELE NON
STRUCTURELLE

De manière générale, tout logiciel doit gérer plusieurs problématiques :

• interactions avec l'extérieur, en particulier l'utilisateur : saisie et contrôle de données, affichage.

C'est la problématique de présentation ;
• opérations sur les données (calculs) en rapport avec les règles métier (« business logic »).
C'est la problématique des traitements ;

• accès et stockage des informations qu'il manipule, notamment entre deux utilisations. C'est la
problématique des données.
 La page Web actuelle mélange code de présentation (les balises HTML) et accès aux données
(requêtes SQL). Ceci est contraire au principe de responsabilité unique. Ce principe de
conception logicielle est le suivant : afin de clarifier l'architecture et de faciliter les évolutions,
une application bien conçue doit être décomposée en sous-parties, chacune ayant un rôle et une
responsabilité particuliers. L'architecture actuelle montre ses limites dès que le contexte se
complexifie. Le volume de code des pages PHP explose et la maintenabilité devient délicate. Il
faut faire mieux

Resultat :

Les principaux défauts de cette page Web sont les suivants :

• elle mélange balises HTML et code PHP ;

• sa structure est monobloc, ce qui rend sa réutilisation difficile.

Le design pattern Modèle-Vue-Contrôleur (MVC) est un pattern architectural qui sépare les
données (le modèle), l'interface homme-machine (la vue) et la logique de contrôle (le
contrôleur).

Ce modèle de conception impose donc une séparation en trois couches :

• le modèle : il représente les données de l'application. Il définit aussi l'interaction avec la base
de données et le traitement de ces données ;
 Nous devrions créer au minimum 3 modèles :

• Client
• BonDeCommande
• Produit

Avec à chaque fois des méthodes spécifiques exemple, nous pourrions avoir

• la vue : elle représente l'interface utilisateur, ce avec quoi il interagit. Elle n'effectue aucun
traitement, elle se contente d'afficher les données que lui fournit le modèle. Il peut tout à fait y
avoir plusieurs vues qui présentent les données d'un même modèle ;
• le contrôleur : il gère l'interface entre le modèle et le client. Il va interpréter la requête de ce
dernier pour lui envoyer la vue correspondante. Il effectue la synchronisation entre le modèle
et les vues.

Avantages mvc
Organise des applications Web de grande
taille –
Comme il existe une séparation du code entre
les trois niveaux, il devient extrêmement facile
de diviser et d’organiser la logique
d’application Web en applications à grande
échelle (qui doivent être gérées par de grandes
équipes de développeurs). Le principal
avantage de l’utilisation de ces pratiques de
code est qu’elles aident à trouver rapidement
des portions de code spécifiques et permettent
l’ajout de nouvelles fonctionnalités en toute
simplicité.

• Facilement modifiable –
L’utilisation de la méthodologie MVC permet une modification facile de l’ensemble de
l’application. L’ajout/la mise à jour du nouveau type de vues est simplifié dans le modèle MVC
(car une seule section est indépendante des autres sections). Ainsi, tout changement dans une
certaine section de l’application n’affectera jamais l’ensemble de l’architecture. Ceci, à son
tour, contribuera à augmenter la flexibilité et l’évolutivité de l’application.

Processus de développement plus rapide –

Comme il existe une séparation du code entre les trois niveaux, le développement d’applications
Web à l’aide du modèle MVC permet à un développeur de travailler sur une section particulière
(par exemple, la vue) tandis qu’un autre peut travailler sur n’importe quelle autre section (par
exemple, la contrôleur) simultanément. Cela permet une mise en œuvre facile de la logique
métier et contribue à quadrupler le processus de développement. Il a été observé que par rapport
à d’autres modèles de
développement, le modèle MVC finit par afficher des vitesses de développement plus élevées
(jusqu’à trois
fois).

Planification et maintenance faciles –

Le paradigme MVC est utile pendant la phase de planification initiale de l’application car il
donne au développeur un aperçu de la façon d’organiser ses idées en code réel. C’est également
 un excellent outil pour aider à limiter la duplication de code et permettre une maintenance facile
de l’application.

Router

en plus du MVC classique, nous allons ajouter une dernière brique « essentiel » au bon
fonctionnement et à la maintenance de votre site Internet. Cette brique est nommée un Routeur.

Le routeur va contenir la déclaration des « liens » de votre site Internet afin de les aiguiller vers
la bonne fonctionnalité dans votre contrôleur.

Nous pouvons schématiser le fonctionnement :

• Les Modèles (Models)

o Ce que nous appelons un Modèle est en réalité un fichier PHP qui ne fait que gérer les échanges
avec la base de données. Lorsque nous avons besoin de lire ou écrire dans la base de données,
nous faisons appel au Modèle.
o Le modèle est la couche représentant les données. On l’appellera parfois logique métier.
o Le modèle consiste en une série de classes. Si les données sont tirées de la BD, chacune des
classes représentera une table.
o Parmi les fonctionnalités codées dans le modèle, on retrouve les relations entre les tables, les
accesseurs et modificateurs, les champs calculés, etc.
• Les Vues (Views) o La vue est constituée de balises HTML qui représentent ce qui sera affiché
à l’écran, c’est une interface utilisateur.
o En plus des balises HTML, la vue peut utiliser des directives et instructions prévues par le
moteur d’affichage afin d’effectuer différentes opérations, comme par exemple tester une
condition ou encore boucler dans les données fournies par le modèle.
o La vue pourra faire appel à des ressources externes, comme des feuilles de style, des fichiers
JavaScript, des images, etc. o Sous Laravel, le moteur d’affichage s’appelle Blade.
• Les Contrôleurs (Controllers) o Véritable tour de contrôle de notre application, le contrôleur a
pour fonction de faire l’interface entre les modèles et les vues. Il est chargé de demander les
données par l’intermédiaire des modèles, de traiter ces données et de les transmettre aux vues,
prêtes à être utilisées.

• Le routing
o Bien qu’indépendant de l’architecture MVC, le routing fait partie intégrante de tous les
Frameworks PHP.
o Dans une architecture classique, nous pointons vers des fichiers :
 http://monsite.fr/index.php
 http://monsite.fr/inscription.php
 http://monsite.fr/login.php
o …
• Dans une architecture MVC, nous allons pointer vers des dossiers virtuels appelés routes o
http://monsite.fr/user/inscription o http://monsite.fr/user/login o http://monsite.fr/blog/article
• …
• Cette architecture offre de nombreux avantages :
o Protection des fichiers, ceux-ci n’étant plus affichés par le navigateur o Des URLs plus
simples à mémoriser pour les utilisateurs o Amélioration du référencement si les routes
contiennent des mots-clés contenus dans la page correspondante
• Le schéma ci-dessus montre le cheminement du traitement à partir d’un URL jusqu’à
l’affichage d’une page Web.
o On y voit, en rouge, que Laravel commence par rechercher une route qui correspond à l’URL
(ici : « / »).
o On y voit en bleu qu’ensuite, Laravel va appeler le contrôleur indiqué dans le « uses » de la
route (ici : PagesController). Plus précisément, en vert, on voit le nom de la méthode d’action
à exécuter dans ce contrôler (ici : accueil).
o En rose, on voit que Laravel va afficher la vue mentionnée dans la méthode d’action. La vue
doit être placée dans un sous-dossier de ressources/views (ici : pages) et porter le nom spécifié
(ici :
accueil).
o C’est ainsi qu’on obtient à l’écran le visuel de l’URL demandé.