Modèle État
Fait partie de la section Programmation Orientée Objet du Journey GO de Coddy. Leçon 95 sur 107.
Le pattern State permet à un objet de modifier son comportement lorsque son état interne change, donnant l’impression que l’objet a changé de classe. Alors que Template Method contrôle les étapes de l’algorithme, State encapsule le comportement propre à chaque état dans des objets distincts et délègue à l’état actuel.
En Go, nous définissons une interface d’état et créons des états concrets qui implémentent différents comportements :
type State interface {
Handle(d *Document) string
}
type Document struct {
state State
}
func (d *Document) SetState(s State) {
d.state = s
}
func (d *Document) Publish() string {
return d.state.Handle(d)
}Chaque état détermine ce qui se passe et quel état vient ensuite :
type DraftState struct{}
func (s DraftState) Handle(d *Document) string {
d.SetState(ModerationState{})
return "Draft submitted for moderation"
}
type ModerationState struct{}
func (s ModerationState) Handle(d *Document) string {
d.SetState(PublishedState{})
return "Moderation approved, now published"
}
type PublishedState struct{}
func (s PublishedState) Handle(d *Document) string {
return "Already published"
}Le même appel de méthode produit des résultats différents selon l’état actuel :
doc := &Document{state: DraftState{}}
fmt.Println(doc.Publish()) // Brouillon soumis pour modération
fmt.Println(doc.Publish()) // Modération approuvée, maintenant publié
fmt.Println(doc.Publish()) // Déjà publiéState est idéal pour les objets ayant des modes de fonctionnement distincts, tels que les flux de traitement des commandes, les composants d’interface utilisateur ou les gestionnaires de connexions dont le comportement dépend entièrement de l’état actuel.
Défi
FacileConstruisons un système de gestion des tickets d'assistance en utilisant le pattern State ! Vous allez créer un ticket d'assistance qui passe par différentes étapes, de son ouverture à sa résolution, en passant par sa prise en charge, chaque état déterminant les actions possibles et ce qui se passe ensuite.
Vous allez organiser votre code sur trois fichiers :
state.go: définissez votre interface d'état ainsi que les états concrets qui représentent chaque étape du cycle de vie d'un ticket.Créez une interface
TicketStateavec une méthodeHandle(t *Ticket) stringqui traite le ticket et le fait éventuellement passer à l'état suivant.Implémentez trois états :
OpenState: lorsqu'il est traité, fait passer le ticket àInProgressStateet renvoieTicket opened, assigning to support teamInProgressState: lorsqu'il est traité, fait passer le ticket àResolvedStateet renvoieWorking on ticket, issue resolvedResolvedState: lorsqu'il est traité, reste dans le même état et renvoieTicket already resolved
ticket.go: créez votre structure de ticket, qui contient l'état actuel et lui délègue le comportement.Construisez une structure
Ticketavec un champID(string) et un champstate(TicketState). Ajoutez ces méthodes :SetState(s TicketState)pour modifier l'état actuel du ticketProcess() stringqui délègue le traitement à la méthode Handle de l'état actuel
Créez un constructeur
NewTicket(id string) *Ticketqui renvoie un ticket commençant dans l'étatOpenState.main.go: montrez comment une même action produit des résultats différents selon l'état actuel du ticket.Lisez l'identifiant d'un ticket ainsi que le nombre de fois où le ticket doit être traité. Créez un nouveau ticket avec cet identifiant, puis appelez
Process()le nombre de fois indiqué, en affichant chaque résultat sur une ligne distincte.
Les entrées suivantes seront fournies :
- Ligne 1 : identifiant du ticket
- Ligne 2 : nombre de fois où traiter le ticket
Par exemple, étant donné :
TKT-001
3Votre sortie doit être :
Ticket opened, assigning to support team
Working on ticket, issue resolved
Ticket already resolvedEt étant donné :
TKT-500
5Votre sortie doit être :
Ticket opened, assigning to support team
Working on ticket, issue resolved
Ticket already resolved
Ticket already resolved
Ticket already resolvedEt étant donné :
ISSUE-42
1Votre sortie doit être :
Ticket opened, assigning to support teamRemarquez qu'appeler Process() sur le même ticket produit des résultats différents à chaque fois : le comportement du ticket change à mesure qu'il passe d'un état à l'autre. Une fois résolu, il reste résolu, quel que soit le nombre de fois où vous le traitez. L'objet ticket semble modifier son comportement, mais en réalité, il délègue ce comportement à différents objets d'état !
Essayez vous-même
package main
import (
"fmt"
)
func main() {
// Lire l'entrée
var ticketID string
var numProcesses int
fmt.Scanln(&ticketID)
fmt.Scanln(&numProcesses)
// TODO: Créer un nouveau ticket avec l'ID donné
// TODO: Traiter le ticket le nombre de fois spécifié
// et imprimer chaque résultat sur une ligne séparée
}
Cette leçon comprend un petit quiz. Commencez la leçon pour y répondre et suivre votre progression.
Toutes les leçons de Programmation Orientée Objet
1Fondamentaux de la POO en Go
Fichiers externesEspace de travail et modules GoPackages et importsNoms exportés et non exportésIntroduction à la POO en GoStructs comme classesDéfinir des méthodes sur des structsRécepteurs pointeurs ou par valeurInitialisation des structsFonctions constructeursRécapitulatif - Calculatrice simple4Interfaces
Introduction aux interfacesImplémentation impliciteL’interface comme contratInterface vide (any)Assertion de typeCommutation de typeComposition d’interfacesInterfaces Stringer et ErrorRécapitulatif - Calculateur de formes7Encapsulation
Champs exportés vs non exportésEncapsulation au niveau du packageMéthodes Getter et SetterDissimulation de l’information en GoRécapitulatif – Fiches d’étudiants10Génériques (Go 1.18+)
Introduction aux génériquesParamètres de typeContraintes de typeStructures génériquesSolution de contournement pour les méthodes génériquesRécapitulatif - Collection générique2Plongée approfondie dans les types et les structs
Types de base et compositesDéfinitions de types personnalisésTags de structStructs anonymesStructs imbriquésValeurs zéro et valeurs par défautRécapitulatif - Carnet de contacts5La composition plutôt que l’héritage
Pourquoi Go n’a pas d’héritageBases de l’inclusion de structsPromotion des méthodesInclure plusieurs structsInclusion ou agrégationMasquage des méthodes inclusesRécapitulatif : hiérarchie des employés8Gestion des erreurs et POO
L’interface errorTypes d’erreurs personnalisésEnrobage des erreurs (fmt.Errorf)Erreurs sentinelleserrors.Is() et errors.As()Panic, Defer et RecoverRécapitulatif - Analyseur de fichiers11Bibliothèque standard et POO
io.Reader et io.Writersort.InterfaceInterface fmt.Stringerencoding/json avec des structsInterface http.HandlerRécapitulatif - Modèles d’API REST14Modèles de conception – Partie 2
Modèle CommandeModèle AdaptateurModèle DécorateurModèle Méthode modèleModèle ÉtatModèle CompositeMiddleware comme décorateur3Pointeurs et mémoire
Notions de base des pointeurs en GoPointeurs vers des structuresPassage par valeur ou par référenceLa fonction new()Garbage collection en GoRécapitulatif - Constructeur de listes chaînées6Polymorphisme en Go
Polymorphisme via les interfacesDuck typing en GoRègles de satisfaction des interfacesCollections polymorphesInjection de dépendancesRécapitulatif – Processeur de paiements9Concurrence et POO
Bases des GoroutinesCanaux et communicationCanaux tamponnés ou non tamponnésInstruction selectsync.Mutex et sync.RWMutexsync.WaitGroupConception de structures thread-safeRécapitulatif - Pool de workersEntraînez-vous par vous-même : Compilateur Go en ligne