Introduction à la chaîne de responsabilité

Cet article explique et démontre le modèle de conception de la chaîne de responsabilité.

Concepts clés

La chaîne de responsabilité (COR) est un modèle de conception comportementale qui achemine une demande à travers une séquence d'objets de traitement (gestionnaires). Ceci est particulièrement utile lorsque: le gestionnaire approprié n'est pas connu au préalable, une sélection automatique des gestionnaires est nécessaire, ou la demande doit suivre une chaîne prioritaire.

COR intègre bien d'autres modèles, tels que le modèle composite, permettant un traitement uniforme du gestionnaire et un transfert de demande. Sa structure flexible favorise le couplage et l'adaptation lâches.

Les performances peuvent être améliorées à l'aide d'un conteneur de service pour l'instanciation des objets et un mécanisme de mise en cache pour stocker et réutiliser les réponses pour les demandes identiques.

Définition

COR traite une demande en le faisant passer par une chaîne d'objets de gestionnaire. Une demande peut être traitée par un seul gestionnaire ou plusieurs, selon la mise en œuvre. Tous les gestionnaires participent à la chaîne.

Des exemples simples incluent: une transaction ATM (entrée de broche, retrait du montant, impression de réception) et un appel d'assistance (navigation de menu, étapes guidées).

Participants

Les composants centraux sont:

• Handler: Définit une interface pour la gestion des demandes. Il peut s'agir d'une classe abstraite, fournissant éventuellement des méthodes par défaut et une affectation successeur.
• Handleurs en béton: Profiter les demandes et peuvent les transmettre aux successeurs.

Les ajouts facultatifs incluent: un objet client initiant la demande et configurant la chaîne; un objet de demande; un objet de réponse; et autres modèles de conception.

Cas d'utilisation

cor brille quand:

• La sélection des gestionnaires est automatique (par exemple, journalisation).
• Le gestionnaire est inconnu à l'avance (par exemple, manipulation des exceptions).
• Les demandes doivent suivre un ordre prioritaire spécifique, potentiellement dynamique (par exemple, l'événement ou la propagation de commande).

Implémentation de base (PHP)

COR se marie souvent avec le motif composite. Voici un exemple de PHP de base:

<?php
abstract class BasicHandler {
    private $successor = null;

    public function setSuccessor(BasicHandler $handler) {
        $this->successor = $handler;
    }

    abstract public function handle($request);
}

class FirstHandler extends BasicHandler {
    public function handle($request) {
        // Process request...  Then optionally:
        if ($this->successor) {
            return $this->successor->handle($request);
        }
        return null; // Or a response
    }
}

// ... SecondHandler, ThirdHandler classes ...

$first = new FirstHandler();
$second = new SecondHandler();
$third = new ThirdHandler();

$first->setSuccessor($second);
$second->setSuccessor($third);

$result = $first->handle($request);
?>

Implémentation avancée (PHP)

La force de

COR réside dans son organisation de chaîne flexible. Cet exemple démontre la restructuration et l'adaptation:

<?php
abstract class AdvancedHandler {
    private $successor = null;

    final public function setSuccessor(AdvancedHandler $handler) {
        if ($this->successor === null) {
            $this->successor = $handler;
        } else {
            $this->successor->setSuccessor($handler);
        }
    }

    final public function handle($request) {
        $response = $this->process($request);
        if ($response === null && $this->successor !== null) {
            return $this->successor->handle($request);
        }
        return $response;
    }

    abstract protected function process($request);
}

class FirstHandler extends AdvancedHandler {
    protected function process($request) {
        // Process request... return null to pass to successor, or a response
    }
}

// ... SecondHandler, ThirdHandler classes ...

$first = new FirstHandler();
$second = new SecondHandler();
$third = new ThirdHandler();

$first->setSuccessor($second);
$first->setSuccessor($third); // Adds to the end of the chain

$result = $first->handle($request);
?>

Cela minimise les méthodes dans les gestionnaires de béton, améliorant la cohésion. D'autres raffinements pourraient impliquer un objet Response structuré ou une intégration avec d'autres modèles.

Configuration de la chaîne

La configuration de la chaîne de séparation améliore la clarté du code et la maintenabilité. L'injection de dépendance, potentiellement à l'aide d'un fichier de configuration YAML, offre une approche propre:

class Client {
    private $firstHandler;

    public function setChainOrder(array $handlers) {
        // Code to build the chain using $handlers
    }

    public function process($request) {
        return $this->firstHandler->handle($request);
    }
}

Optimisation des performances

Pour les applications critiques de performance avec des gestionnaires complexes et des demandes fréquentes, considérez:

• Conteneur de service: Gérer l'instanciation des objets pour éviter la création répétée.
• CACHING: stocker et réutiliser les réponses pour les demandes identiques en utilisant un mécanisme comme le motif de poids mouche. Cela pourrait être intégré dans la classe AdvancedHandler.

Conclusion

COR est un motif puissant, permettant même des chaînes de chaînes. Tout en favorisant un couplage lâche, une conception minutieuse est cruciale pour éviter les problèmes potentiels. Analysez en profondeur votre problème avant de mettre en œuvre COR, en accordant une attention particulière à la définition du gestionnaire, aux interactions de demande / réponse et aux goulots d'étranglement potentiels de performance.

Questions fréquemment posées (FAQ) (Celles-ci sont déjà bien adressées dans le texte d'origine, donc je ne les répéterai pas ici. Le texte original fournit d'excellentes réponses.)

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!