Maison  >  Article  >  développement back-end  >  Modèles de conception PHP : malentendus et pièges courants

Modèles de conception PHP : malentendus et pièges courants

WBOY
WBOYoriginal
2024-06-03 18:57:00474parcourir

Bien que les modèles de conception en PHP présentent des avantages, il existe également des malentendus et des pièges lors de leur utilisation, tels que l'utilisation aveugle, la violation du principe de responsabilité unique, la confusion entre héritage et délégation, l'abus du modèle de méthode d'usine et la mauvaise implémentation du principe SOLID. . Une bonne application des modèles de conception, comme la séparation de la responsabilité du calcul du montant total à travers le modèle de chaîne de responsabilité, peut améliorer la modularité et la maintenabilité du code.

Modèles de conception PHP : malentendus et pièges courants

Modèles de conception PHP : malentendus et pièges courants

Les modèles de conception sont des outils précieux pour la réutilisation du code, réduisant le code en double et améliorant l'efficacité du développement. Cependant, il existe certains malentendus et pièges courants lors de l'utilisation de modèles de conception en PHP :

Mythe 1 : Utiliser aveuglément des modèles de conception

Toutes les situations ne conviennent pas à l'utilisation de modèles de conception. Une utilisation prématurée ou excessive des modèles de conception peut entraîner une complexité et des frais inutiles. Lorsque vous choisissez un modèle de conception, vous devez soigneusement examiner son adéquation et son impact sur votre code.

Mythe 2 : Incompréhension du principe de responsabilité unique (SRP)

SRP signifie qu'une classe ne devrait avoir qu'une seule raison de changer. La violation de SRP entraîne un code faiblement couplé et difficile à maintenir. L'utilisation de modèles de conception tels que la réutilisation compositionnelle, l'agrégation et l'injection de dépendances peuvent contribuer à appliquer le SRP.

Mythe 3 : Confondre héritage et délégation

L'héritage est une manière de créer une nouvelle classe et d'hériter de ses propriétés d'une classe existante. La délégation permet à une classe de déléguer à une autre classe pour effectuer une tâche spécifique. Confondre héritage et délégation peut entraîner des problèmes d’évolutivité et de maintenabilité dans votre code.

Mythe 4 : Abus du modèle de méthode d'usine

Le modèle de méthode d'usine peut aider à créer et à gérer des objets, mais son utilisation excessive peut créer des objets sacrés (Singleton) et des conteneurs d'injection de dépendance (DI). Utilisez le modèle de méthode d'usine avec parcimonie et uniquement lorsque vous devez créer des objets d'un type spécifique.

Mythe 5 : Mauvaise implémentation de SOLID

Les principes SOLID (responsabilité unique, ouvert-fermé, substitution de Liskov, isolation d'interface et inversion de dépendance) fournissent des conseils pour la conception d'un code bien entretenu. Cependant, si les principes SOLID ne sont pas appliqués correctement, cela peut entraîner des problèmes d'évolutivité et des structures difficiles à comprendre dans votre code.

Cas pratique :

Considérons un système de panier d'achat, où la classe Cart est chargée de gérer les articles dans le panier de l'utilisateur. Nous souhaitons calculer le montant total en fonction des articles présents dans le panier. Cart 类负责管理用户购物车的物品。我们想根据购物车的物品计算总金额。

错误实施:

class Cart {
  private $items;

  public function __construct() {
    $this->items = [];
  }

  public function addItem(Item $item) {
    $this->items[] = $item;
  }

  public function calculateTotalAmount() {
    $total = 0;
    foreach ($this->items as $item) {
      $total += $item->getPrice();
    }
    return $total;
  }
}

这个实现违反了 SRP,因为 Cart 类既负责存储物品又负责计算总金额。

改进的实现:

我们可以使用职责链模式来分离计算总金额的职责:

interface TotalCalculator {
  public function calculateTotal(array $items);
}

class ItemTotalCalculator implements TotalCalculator {
  public function calculateTotal(array $items) {
    $total = 0;
    foreach ($items as $item) {
      $total += $item->getPrice();
    }
    return $total;
  }
}

class Cart {
  private $items;
  private $totalCalculator;

  public function __construct(TotalCalculator $totalCalculator) {
    $this->items = [];
    $this->totalCalculator = $totalCalculator;
  }

  public function addItem(Item $item) {
    $this->items[] = $item;
  }

  public function calculateTotalAmount() {
    return $this->totalCalculator->calculateTotal($this->items);
  }
}

通过职责链模式,我们分离了计算总金额的职责,使 Cart

🎜Mauvaise implémentation : 🎜🎜rrreee🎜Cette implémentation viole le SRP car la classe Cart est responsable à la fois du stockage de l'article et du calcul du montant total. 🎜🎜🎜Mise en œuvre améliorée :🎜🎜🎜Nous pouvons utiliser le modèle de chaîne de responsabilité pour séparer la responsabilité du calcul du montant total :🎜rrreee🎜Avec le modèle de chaîne de responsabilité, nous séparons la responsabilité du calcul du montant total, ce qui fait Cart Le code est plus modulaire et maintenable. 🎜

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!

Déclaration:
Le contenu de cet article est volontairement contribué par les internautes et les droits d'auteur appartiennent à l'auteur original. Ce site n'assume aucune responsabilité légale correspondante. Si vous trouvez un contenu suspecté de plagiat ou de contrefaçon, veuillez contacter admin@php.cn