Editions ENI Livres | Vidéos | e-Formations
Le design pattern Flyweight
Description
Le but du design pattern Flyweight est de partager de façon efficace un ensemble important d’objets de granularité fine.
Exemple
Dans le système de vente de véhicules, il est nécessaire de gérer les options que l’acheteur peut choisir lorsqu’il commande un nouveau véhicule. Ces options sont décrites dans la classe OptionVehicule.
Pour chaque véhicule commandé, il est possible d’associer une nouvelle instance de cette classe. Cependant, un grand nombre d’options sont souvent présentes pour chaque véhicule commandé, ce qui oblige le système à gérer un grand ensemble d’objets simples et donc de petite taille (de grain fin). Cette approche présente toutefois l’avantage de pouvoir stocker au niveau de l’option des informations spécifiques à celle-ci et au véhicule comme le prix de vente de l’option qui peut différer d’un véhicule commandé à un autre.
Cette solution est présentée sur un exemple à la figure 15.1 et il est aisé de se rendre compte qu’un grand nombre d’instances de OptionVehicule doit être géré alors que nombre d’entre elles contiennent des données identiques.
Figure 15.1 - Exemple d’absence de partage d’objets de grain fin
Le design pattern Flyweight propose une solution à ce problème en partageant les options :
-
Le partage est réalisé par une fabrique à...
Structure
1. Diagramme de classes
La figure 15.3 détaille la structure générique du design pattern Flyweight.
Figure 15.3 - Structure du design pattern Flyweight
2. Participants
Les participants au design pattern Flyweight sont les suivants :
-
FabriqueFlyweight (FabriqueOption) crée et gère les objets poids mouches. La fabrique s’assure que ceux-ci sont partagés grâce à la méthode getFlyweight qui renvoie leurs références.
-
Flyweight (OptionVehicule) détient l’état intrinsèque et implémente les méthodes. Ces méthodes reçoivent et déterminent également l’état extrinsèque des objets poids mouches.
-
Client (VehiculeCommande) contient un ensemble de références vers les poids mouches qu’il utilise. Le client doit également détenir l’état extrinsèque de ces objets.
3. Collaborations
Les clients ne doivent pas créer eux-mêmes les objets poids mouches mais utiliser la méthode getFlyweight de la fabrique FabriqueFlyweight qui garantit que les instances sont partagées.
Lorsqu’un client invoque une méthode d’un poids mouche, il doit lui transmettre son état extrinsèque.
Domaine d’application
Le domaine d’application du design pattern Flyweight est le partage de petits objets (poids mouches). Les critères d’utilisation sont les suivants :
-
Le système utilise un grand nombre d’objets de granularité fine et leur stockage se révèle coûteux.
-
Il existe de nombreux ensembles d’objets qui peuvent être remplacés par quelques objets partagés une fois qu’une partie de leur état est rendue extrinsèque.
Exemple en PHP
La classe OptionVehicule possède un constructeur qui permet de définir l’état intrinsèque de l’option. Cet état se limite à une chaîne de caractères stockant son nom.
La méthode affiche prend comme paramètre un tableau constitué du prix de vente de l’option et de sa référence dans le catalogue. Ces informations constituent l’état extrinsèque de l’objet.
<?php
declare(strict_types=1);
namespace ENI\DesignPatterns\Flyweight;
class OptionVehicule
{
protected string $nom;
public function __construct(string $nom)
{
$this->nom = $nom;
}
public function affiche(array $contexte): void
{
echo 'Option' . PHP_EOL;
echo 'Nom: ' . $this->nom . PHP_EOL;
foreach ($contexte as $cle => $valeur) {
echo ucfirst($cle) . ': ' . $valeur . PHP_EOL;
}
}
} La classe FabriqueOption gère le partage des options à l’aide d’un tableau indexé...