Parlons en profondeur du « Modèle de chaîne de responsabilité », un puissant outil de modèle de conception (avec processus de mise en œuvre go)

Cet article vous apporte des connaissances pertinentes sur les modèles de conception Golang. Il présente principalement ce qu'est le modèle de chaîne de responsabilité et sa valeur, ainsi que la méthode de mise en œuvre spécifique du code Go de la chaîne de responsabilité. vous sera utile. Les amis qui ont besoin d'aide.

Aujourd'hui, je vais continuer à mettre à jour les articles liés aux modèles de conception. Dans les deux articles précédents sur le modèle de modèle et le modèle de stratégie, je vous ai parlé d'une "théorie violente" que j'ai résumée : "Trois modèles de conception : modèle, stratégie et chaîne de responsabilité. C'est un outil puissant pour résoudre le problème des processus complexes et changeants du système d'entreprise". Dans cet article, parlons du troisième outil de modèle de conception : le modèle de chaîne de responsabilité.

Modèle de chaîne de responsabilité

Chaîne de responsabilité - le nom anglais Chain of responsabilisation est parfois traduit par modèle de chaîne de responsabilité. Je vois qu'il y a d'autres noms sur Internet appelés chaîne de responsabilité, mais ici tout le monde sait qu'il s'agit de la même chose.

C'est un modèle de conception comportementale. En utilisant ce modèle, nous pouvons créer un lien composé de plusieurs processeurs pour les requêtes. Chaque processeur est responsable de ses propres responsabilités et n'est pas couplé les uns aux autres. Après avoir terminé ses propres tâches, l'objet de requête est transmis au suivant dans le lien. . processeur pour le traitement.

La chaîne de responsabilité est utilisée dans de nombreux frameworks populaires. Les composants du framework tels que les middlewares et les intercepteurs appliquent tous ce modèle de conception. Vous devriez utiliser ces deux composants plus souvent. Lors du développement d'interfaces Web, des opérations courantes de projet similaires telles que l'enregistrement des journaux d'accès, l'analyse des jetons et le formatage de la structure unifiée des réponses de l'interface sont toutes réalisées dans le middleware et les intercepteurs, afin que ces opérations de base puissent être intégrées à l'interface. découplé.

Les composants du middleware et des intercepteurs sont conçus pour nous par le framework et peuvent y être directement insérés. Ce dont nous allons parler dans l'article d'aujourd'hui est de savoir comment appliquer la chaîne de responsabilité à la conception de nos processus métier de base, et pas seulement. Faites simplement les opérations publiques de base.

La valeur de la chaîne de responsabilité

Ci-dessus, nous avons parlé de quelques applications de la chaîne de responsabilité dans les composantes publiques du projet, nous permettant d'ajouter quelques fonctions communes de base aux pré- et post-processus de la logique fondamentale. Mais en fait, dans certaines activités principales, l'application du modèle de chaîne de responsabilité nous permet d'étendre sans douleur les étapes du processus métier.

Par exemple, lorsque Taobao a été créé, le processus de traitement des commandes d'achats était peut-être ainsi au début.

Modèle de chaîne de responsabilité - commande d'achat - version pure

L'ensemble du processus est relativement propre "Vérification des paramètres utilisateur - vérification des données du panier - vérification de l'inventaire des produits - calcul du fret - déduction des stocks - génération de commandes" , Let's appelez-le la version pure du processus de commande. Cela se produit généralement lorsque le produit passe de 0 à 1. Pour les achats en ligne, vous pouvez simplement sélectionner des produits, passer des commandes et payer en ligne.

Mais nous sommes tous des vétérans de la navigation sur Internet, et nous le connaissons tous. Si ce processus reste aussi pur, le PM et les opérations de l'entreprise peuvent partir. Une fois que le site Web d'achat est opérationnel et qu'il y a des consommateurs, afin d'augmenter les ventes, certaines méthodes de promotion telles que des remises complètes sur certaines catégories de produits seront généralement ajoutées.

Les opérations ne peuvent pas rester inactives, parler davantage des clients, créer un festival de shopping, puis organiser des coupons pour attirer plus d'utilisateurs. De cette manière, lors du processus de passation d'une commande, il est nécessaire de déterminer si les produits dans le panier remplissent les conditions de réduction, si l'utilisateur dispose d'un coupon et, si tel est le cas, le montant peut être réduit ou réduit. Cela équivaut à ajouter deux sous-processus au milieu de notre processus de commande interne.

Modèle de chaîne de responsabilité - Commande d'achat - Version expérimentée

Afin de mettre en œuvre la logique nouvellement ajoutée, nous devons ajouter au moins deux branches if else au processus de commande écrite pour ajouter ces deux logiques. Mais le plus terrible, c'est queParce que l'ensemble du processus est couplé, après modification, nous devons tester l'ensemble du processus. Et sur la base de l'expérience ci-dessus, nous devons également savoir que ce processus sera certainement étendu à l'avenir. Par exemple, nous ajouterons des fonctions telles que la découpe et la commande communautaires à l'avenir, chaque fois que vous ajouterez des étapes au processus de génération de commandes. , vous devrez modifier les étapes déjà écrites. Avez-vous peur du code ?

Certains amis diront peut-être que le processus d'achat en ligne sur Internet peut en effet être très diversifié et que le processus de chaque entreprise est différent. Prenons un autre exemple d'un patient se rendant à l'hôpital pour consulter un médecin. Les étapes de base pour qu'un patient consulte un médecin sont :

Inscription—>Voir un médecin à la clinique—>Paiement au bureau de facturation— >Obtenir des médicaments en pharmacie

Cependant, certains patients peuvent avoir besoin d'analyses de laboratoire, de films, etc. Leur processus de traitement médical à l'hôpital peut être le suivant :

Inscription—>Consultation initiale—> >Faire payer le paiement au bureau -> Obtenir les médicaments à la pharmacie

Par conséquent, le processus de traitement médical augmentera également le nombre d'étapes en fonction de l'état du patient.

Maintenant, nous pouvons confirmer : Si les étapes d'un processus ne sont pas fixes, afin d'ajouter des étapes au processus sans modifier le processus original développé et testé, nous devons découpler les différentes étapes de l'ensemble du processus pour augmenter le processus. évolutivité du processus, vous pouvez utiliser le modèle de chaîne de responsabilité. Ce modèle nous permet de définir d'abord les étapes du maillon du processus, puis de les exécuter.

Utiliser le modèle de chaîne de responsabilité pour mettre en œuvre le processus

Si on nous demandait de concevoir la chaîne de responsabilité, comment devrions-nous la concevoir ? Quelles méthodes proposer et mettre en œuvre ? Comment l’utiliser pour enchaîner les étapes du processus ? Ici, nous utilisons le modèle de chaîne de responsabilité pour mettre en œuvre les étapes du processus dans le scénario de consultation d'un médecin pour vous faire une démonstration. Le processus d'achat et de passation d'une commande est similaire. Nous pouvons essayer de le mettre en œuvre nous-mêmes. du modèle de chaîne de responsabilité et faites quelques exemples simulés. Une fois que vous l'avez maîtrisé, vous pouvez essayer de l'utiliser pour résoudre des problèmes commerciaux.

Tout d'abord, nous pouvons penser aux problèmes de l'expansion du processus ci-dessus. Chaque étape du processus doit être complétée par un objet de traitement pour compléter l'abstraction logique. Tous les objets de traitement doivent fournir une méthode unifiée de traitement de leur propre logique. Deuxièmement, ils doivent également maintenir des liens vers le suivant. Pour traiter la référence de l'objet, une fois la logique de l'étape en cours traitée, la méthode de traitement de l'objet suivant est appelée et la requête est transmise à l'objet suivant. pour le traitement, et le processus se déroule en séquence jusqu'à la fin du processus.

Pour résumer, les objets qui implémentent le modèle de chaîne de responsabilité doivent contenir au moins les fonctionnalités suivantes :

• Attributs des membres
  • nextHandler : la prochaine instance d'objet en attente d'être appelée
nextHandler: 下一个等待被调用的对象实例

成员方法

• SetNext: 把下一个对象的实例绑定到当前对象的nextHandler属性上；
• Do: 当前对象业务逻辑入口，他是每个处理对象实现自己逻辑的地方；
• Execute: 负责职责链上请求的处理和传递；它会调用当前对象的Do，nextHandler不为空则调用nextHandler.Do；

如果抽象成 UML 类图表示的话，差不多就是下面这个样子。

定义了一个职责链模式处理对象的接口Handler，由ConcreteHandler –具体处理对象的类型来实现。

观察上图以及上面对象特性的分析，其实是能看出 SetNext 和 Execute 这两个行为是每个 ConcreteHandler 都一样的，所以这两个可以交给抽象处理类型来实现，每个具体处理对象再继承抽象类型，即可减少重复操作。

所以责任链模式的抽象和提炼可以进化成下图这样：

了解完职责链模式从接口和类型设计上应该怎么实现后，我们进入代码实现环节，职责链模式如果用纯面向对象的语言实现起来还是很方便的，把上面的UML类图直接翻译成接口、抽象类，再搞几个实现类就完事。

想把上面这个UML类图翻译成Go代码还是有点难度的。这里咱们提供一个用 Go 实现职责链模式完成医院就诊流程的代码示例。

职责链 Go 代码实现

虽然 Go 不支持继承，不过我们还是能用类型的匿名组合来实现，下面以病人去医院看病这个处理流程为例提供一个具体示例。

看病的具体流程如下：

挂号—>诊室看病—>收费处缴费—>药房拿药

我们的目标是利用责任链模式，实现这个流程中的每个步骤，且相互间不耦合，还支持向流程中增加步骤。

先来实现职责链模式里的公共部分—即模式的接口和抽象类

type PatientHandler interface {
 Execute(*patient) error SetNext(PatientHandler) PatientHandler Do(*patient) error}// 充当抽象类型，实现公共方法，抽象方法不实现留给实现类自己实现type Next struct {
 nextHandler PatientHandler}func (n *Next) SetNext(handler PatientHandler) PatientHandler {
 n.nextHandler = handler return handler}func (n *Next) Execute(patient *patient) (err error) {
 // 调用不到外部类型的 Do 方法，所以 Next 不能实现 Do 方法
 if n.nextHandler != nil {
  if err = n.nextHandler.Do(patient); err != nil {
   return
  }

  return n.nextHandler.Execute(patient)
 }

 return}

上面代码中Next类型充当了模式中抽象类的角色，关于这个NextMéthode membre

🎜SetNext : Liez l'instance de l'objet suivant à la propriété nextHandler de l'objet actuel 🎜 Do  : l'entrée de logique métier de l'objet actuel, où chaque objet de traitement implémente sa propre logique 🎜Execute : responsable du traitement et de la livraison des requêtes dans ; la chaîne de responsabilité ; il appellera Si le Do de l'objet courant, nextHandler n'est pas vide, appelez nextHandler.Do ul>🎜S'il est résumé dans un diagramme de classes UML, il ressemblerait à ce qui suit. 🎜🎜🎜🎜 définit une interface Handler pour les objets de traitement en mode chaîne de responsabilité, qui est implémentée par ConcreteHandler - le type d'objet de traitement spécifique. 🎜🎜En observant l'image ci-dessus et l'analyse des caractéristiques de l'objet ci-dessus, nous pouvons effectivement voir que les deux comportements de SetNext et Execute sont requis par chaque ConcreteHandler La même chose, donc ces deux peuvent être implémentés par des types de traitement abstraits, et chaque objet de traitement spécifique hérite du type abstrait pour réduire les opérations répétées. 🎜🎜Ainsi, l'abstraction et le raffinement du modèle de chaîne de responsabilité peuvent évoluer vers la figure suivante : 🎜🎜<img src="https://img.php.cn/upload/article/000/000/020/2825a64757aefc1a1e4a326bf16d28e4-3.%20png" alt="Êtes-vous également un développeur commercial ? Utilisez ce modèle de conception à l'avance pour éviter des exigences supplémentaires en matière de produit">🎜🎜Après avoir compris comment le modèle de chaîne de responsabilité doit être mis en œuvre en termes d'interface et de conception de type, nous entrons dans le Phase d'implémentation du code.Si le modèle de chaîne de responsabilité est utilisé, il est toujours très pratique d'implémenter un langage purement orienté objet. Il suffit de traduire le diagramme de classes UML ci-dessus directement en interfaces et en classes abstraites, puis de créer quelques classes d'implémentation et vous y êtes. fait. 🎜🎜Il est encore un peu difficile de traduire le diagramme de classes UML ci-dessus en code Go. Nous fournissons ici un exemple de code qui utilise Go pour implémenter le modèle de chaîne de responsabilité afin de terminer le processus de traitement hospitalier. 🎜🎜<a name="<strong>%E8%81%8C%E8%B4%A3%E9%93%BE%20Go%20%E4%BB%A3%E7%A0%81%E5%AE%%209E%E7%8E%B0</strong>">🎜🎜🎜🎜Chaîne de responsabilité Implémentation du code Go🎜🎜🎜Bien que Go ne prenne pas en charge l'héritage, nous pouvons toujours utiliser des combinaisons anonymes de types pour l'implémenter. Ce qui suit est un patient en cours à l'hôpital pour consulter un médecin. Un exemple spécifique est fourni en utilisant le flux de traitement comme exemple. 🎜🎜Le processus spécifique du traitement médical est le suivant : 🎜🎜🎜Inscription—>Consulter un médecin à la clinique—>Paiement à la caisse—>Obtenir des médicaments à la pharmacie🎜🎜🎜Notre objectif est d'utiliser le modèle de chaîne de responsabilité pour réaliser chaque étape de ce processus. Ils ne sont pas couplés les uns aux autres et prennent en charge l'ajout d'étapes au processus. 🎜🎜Tout d'abord, implémentons les parties publiques du modèle de chaîne de responsabilité, c'est-à-dire l'interface et la classe abstraite du modèle🎜<pre class="brush:php;toolbar:false">//流程中的请求类--患者type patient struct {  Name              string  RegistrationDone  bool  DoctorCheckUpDone bool  MedicineDone      bool  PaymentDone       bool}</pre>🎜Le type <code>Suivant dans le code ci-dessus agit comme la classe abstraite dans le modèle . À propos de ceci Suivant Le type sera mis en évidence ici. 🎜

在我们的职责链的UML图里有说明Do方法是一个抽象方法，留给具体处理请求的类来实现，所以这里Next类型充当抽象类型，只实现公共方法，抽象方法留给实现类自己实现。并且由于 Go 并不支持继承，即使Next实现了Do方法，也不能达到在父类方法中调用子类方法的效果—即在我们的例子里面用Next 类型的Execute方法调用不到外部实现类型的Do方法。

所以我们这里选择Next类型直接不实现Do方法，这也是在暗示这个类型是专门用作让实现类进行内嵌组合使用的。

接下来我们定义职责链要处理的请求，再回看一下我们的UML图，实现处理逻辑和请求传递的Do、Execute方法的参数都是流程中要处理的请求。这里是医院接诊的流程，所以我们定义一个患者类作为流程的请求。

//流程中的请求类--患者type patient struct {
 Name              string
 RegistrationDone  bool
 DoctorCheckUpDone bool
 MedicineDone      bool
 PaymentDone       bool}

然后我们按照挂号—>诊室看病—>收费处缴费—>药房拿药这个流程定义四个步骤的处理类，来分别实现每个环节的逻辑。

// Reception 挂号处处理器type Reception struct {
 Next}func (r *Reception) Do(p *patient) (err error) {
 if p.RegistrationDone {
  fmt.Println("Patient registration already done")
  return
 }
 fmt.Println("Reception registering patient")
 p.RegistrationDone = true
 return}// Clinic 诊室处理器--用于医生给病人看病type Clinic struct {
 Next}func (d *Clinic) Do(p *patient) (err error) {
 if p.DoctorCheckUpDone {
  fmt.Println("Doctor checkup already done")
  return
 }
 fmt.Println("Doctor checking patient")
 p.DoctorCheckUpDone = true
 return}// Cashier 收费处处理器type Cashier struct {
 Next}func (c *Cashier) Do(p *patient) (err error) {
 if p.PaymentDone {
  fmt.Println("Payment Done")
  return
 }
 fmt.Println("Cashier getting money from patient patient")
 p.PaymentDone = true
 return}// Pharmacy 药房处理器type Pharmacy struct {
 Next}func (m *Pharmacy) Do (p *patient) (err error) {
 if p.MedicineDone {
  fmt.Println("Medicine already given to patient")
  return
 }
 fmt.Println("Pharmacy giving medicine to patient")
 p.MedicineDone = true
 return}

处理器定义好了，怎么给用他们串成患者就诊这个流程呢？

func main() {
 receptionHandler := &Reception{}
 patient := &patient{Name: "abc"}
 // 设置病人看病的链路
 receptionHandler.SetNext(&Clinic{}).SetNext(&Cashier{}).SetNext(&Pharmacy{})
  receptionHandler.Execute(patient)}

上面的链式调用看起来是不是很清爽，嘿嘿别高兴太早，这里边有个BUG— 即Reception接诊挂号这个步骤提供的逻辑没有调用到，所以我们这里再定义个StartHandler 类型，它不提供处理实现只是作为第一个Handler向下转发请求

// StartHandler 不做操作，作为第一个Handler向下转发请求type StartHandler struct {
 Next}// Do 空Handler的Dofunc (h *StartHandler) Do(c *patient) (err error) {
 // 空Handler 这里什么也不做 只是载体 do nothing...
 return}

这也是Go 语法限制，公共方法Exeute并不能像面向对象那样先调用this.Do 再调用this.nextHandler.Do 具体原因咱们上边已经解释过了，如果觉得不清楚的可以拿Java实现一遍看看区别，再琢磨一下为啥Go里边不行。

所以整个流程每个环节都能被正确执行到，应该这样把处理类串起来。

func main() {
 patientHealthHandler := StartHandler{}
 //
 patient := &patient{Name: "abc"}
 // 设置病人看病的链路
 patientHealthHandler.SetNext(&Reception{}).// 挂号
  SetNext(&Clinic{}). // 诊室看病
  SetNext(&Cashier{}). // 收费处交钱
  SetNext(&Pharmacy{}) // 药房拿药
 //还可以扩展，比如中间加入化验科化验，图像科拍片等等

 // 执行上面设置好的业务流程
 if err := patientHealthHandler.Execute(patient); err != nil {
  // 异常
  fmt.Println("Fail | Error:" + err.Error())
  return
 }
 // 成功
 fmt.Println("Success")}

总结

职责链模式所拥有的特点让流程中的每个处理节点都只需关注满足自己处理条件的请求进行处理即可，对于不感兴趣的请求，会直接转发给下一个节点对象进行处理。

另外职责链也可以设置中止条件，针对我们文中的例子就是在Execute方法里加判断，一旦满足中止后就不再继续往链路的下级节点传递请求。Gin 的中间件的abort方法就是按照这个原理实现的，同时这也是职责链跟装饰器模式的一个区别，装饰器模式无法在增强实体的过程中停止，只能执行完整个装饰链路。

后面大家可以看看针对那些可能未来经常会变的核心业务流程，可以在设计初期就考虑使用职责链来实现，减轻未来流程不停迭代时不好扩展的痛点。当然职责链也不是万能的，对于那些固定的流程显然是不适合的。咱们千万不要手里拿着锤子就看什么都是钉子，所有的设计模式一定要用在合适的地方。

既然这里提到了装饰器，那么下一期就写写装饰器吧，不对，装饰器算是代理模式的一个特殊应用，那就还是先介绍代理未来再介绍装饰器吧，这样阅读体验会更好一些。

喜欢这系列文章的朋友们还请多多关注，转发起来吧。

推荐学习：《go视频教程》

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!