Modèle de conception avancé orienté objet PHP : modèle de décorateur

Quel est le motif décorateur ?

S'il y a un changement dans une partie ou la fonctionnalité d'un objet existant, mais que la structure de l'objet d'origine n'a pas besoin d'être modifiée, alors le modèle de conception du décorateur est le plus approprié.

Problèmes et solutions d'application des modèles de décorateurs :

Lorsque nous apprenons pour la première fois la programmation orientée objet, le premier obstacle est souvent de comprendre la relation parent-enfant dans la relation d'héritage. . Au fil du temps, nous nous familiariserons davantage avec cette méthode de programmation. Lorsqu'ils sont confrontés à un nouveau défi, les programmeurs orientés objet expérimentés étendent immédiatement davantage de fonctionnalités à un objet. Cependant, comme tout a un diplôme, seule une utilisation modérée peut assurer le bon développement de ce type de travail.

La base de code devrait avoir une limite sur le nombre de hiérarchies de classes. Si les objets commencent à nécessiter trop de sous-classes, le code correspondant sacrifie la compréhension et la maintenabilité du programmeur. Généralement, j'essaie de faire en sorte qu'il n'y ait pas plus de 3 relations parent-enfant pour un objet. J'ai découvert que tant que davantage de relations parent-enfant sont créées, le code devient confus et incontrôlable. De plus, l’utilisation de papier ordinaire ne peut pas produire une représentation sous forme de diagramme UML d’un objet dans l’application.

Cependant, je ne veux pas empêcher l'utilisation des extensions de classe. En fait, nous étendons souvent les objets en utilisant des solutions appropriées. Cependant, pour certains problèmes, l’utilisation de classes basées sur le modèle de conception du décorateur constitue une meilleure solution.

Le modèle de conception Decorator convient aux situations dans lesquelles les programmeurs passent beaucoup de temps : les changements sont rapides et mineurs, et ont peu d'impact sur le reste de l'application. L'objectif de la conception d'une classe à l'aide du modèle de conception Decorator est d'appliquer des modifications incrémentielles à un objet de base sans avoir à remplacer les fonctionnalités existantes. Les décorateurs sont construits de telle manière qu'il devrait être possible d'insérer un ou plusieurs décorateurs qui modifient ou « décorent » l'objet cible directement dans le flux de code principal sans affecter les autres flux de code.

UML

Le diagramme UML suivant détaille une conception de classe utilisant le modèle de conception du décorateur.

La description suivante de l'image ci-dessus :

1.MyObject est une classe de base avec des fonctionnalités existantes. Cette classe contient un tableau public nommé items et une méthode publique nommée show ItemsFormatted().

2. La méthode show ItemsFormatted() est chargée d'accepter le tableau d'éléments, de formater le tableau à l'aide de fonctionnalités prédéfinies et de soumettre la sortie.

3. La classe MyObjectDecorator contient une instance privée de MyObject et deux méthodes publiques : MyObjectDecorator() et decorItems().

4. La méthode MyObjectDecorator() représente le constructeur, qui accepte un paramètre de type MyObject et le stocke en interne.

5. La méthode decorItems() peut modifier le tableau items de l'instance MyObject.

Regardons l'exemple suivant Afin de calculer la valeur d'une surface, nous écrivons le code comme suit :

// 区域抽象类
abstract class Area
{
    abstract public function treasure();
}
//森林类，价值100
class Forest extends Area 
{
    public function treasure()
    {
        return 100;
    }
}
//沙漠类，价值10
class Desert extends Area
{
    function function treasure()
    {
        return 10;
    }
}

Le code ci-dessus ne semble poser aucun problème, mais si besoin Comment calculer la valeur d'une forêt détruite ? Ajouter une sous-classe DamageForest ? Évidemment, ce n'est pas réalisable, car il y aura probablement de nombreuses autres classes avec des types qui se chevauchent, ce qui entraînera une duplication de code dans la classe et de plus en plus de sous-classes.

Le modèle de décorateur utilise la composition et la délégation au lieu de l'héritage pour résoudre les problèmes ci-dessus. Jetons un coup d'œil au code amélioré suivant :

// 区域抽象类
abstract class Area
{    
   abstract public function treasure();
}

//森林类，价值100
class Forest extends Area 
{
   public function treasure()
   {
       return 100;
   }
}
//沙漠类，价值10
class Desert extends Area
{
   function function treasure()
   {
       return 10;
   }
}
//区域类的装饰器类
abstract class AreaDecorateor extends Area
{
   protected $_area = null;

   public function __construct(Area $area)
   {
       $this->_area = $area;
   }
}

//被破坏了后的区域，价值只有之前的一半
class Damaged extends AreaDecorateor
{
   public function treasure()
   {
       return $this->_area->treasure() * 0.5;
   }
}

//现在我们来获取被破坏的森林类的价值
$damageForest = new Damaged(new Forest());
echo $damageForest->treasure();  //返回50

.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!