Pattern Singleton
Fait partie de la section Programmation Orientée Objet du Journey GO de Coddy. Leçon 86 sur 107.
Le pattern Singleton garantit qu’un type ne possède qu’une seule instance dans l’ensemble de votre programme et fournit un point d’accès global à celle-ci. Cela est utile pour les ressources partagées comme les gestionnaires de configuration, les connexions à une base de données ou les loggers.
En Go, nous implémentons Singleton à l’aide d’une variable au niveau du package combinée à sync.Once afin de garantir une initialisation sûre vis-à-vis des threads :
package config
import "sync"
type Config struct {
DatabaseURL string
MaxRetries int
}
var (
instance *Config
once sync.Once
)
func GetInstance() *Config {
once.Do(func() {
instance = &Config{
DatabaseURL: "localhost:5432",
MaxRetries: 3,
}
})
return instance
}sync.Once garantit que la fonction d’initialisation s’exécute exactement une fois, même lorsque plusieurs goroutines appellent GetInstance() simultanément. Chaque appel ultérieur renvoie la même instance sans réexécuter le code d’initialisation.
cfg1 := config.GetInstance()
cfg2 := config.GetInstance()
// cfg1 et cfg2 pointent vers la même instanceUtilisez Singleton avec parcimonie. Bien que pratique, il introduit un état global qui peut compliquer les tests et masquer les dépendances. Déterminez si l’injection de dépendances pourrait constituer une meilleure alternative pour votre cas d’utilisation.
Défi
FacileConstruisons un singleton Logger qui garantit qu’une seule instance de logger existe dans toute votre application ! C’est un cas d’utilisation classique du modèle Singleton. Vous voulez que toutes les parties de votre programme partagent la même configuration et le même état du logger.
Vous allez organiser votre code sur deux fichiers :
logger.go: implémentez votre logger Singleton thread-safe.Créez une structure
Loggeravec deux champs :Prefix(string) pour les préfixes des messages de log, etMessageCount(int) pour suivre le nombre de messages enregistrés.Utilisez des variables au niveau du package avec
sync.Oncepour garantir qu’une seule instance est créée. Implémentez une fonctionGetLogger()qui initialise le logger avec le préfixe par défaut"[LOG]"et renvoie l’instance singleton.Ajoutez ces méthodes à votre Logger :
SetPrefix(prefix string)- modifie le préfixe du loggerLog(message string) string- incrémente le compteur de messages et renvoie une chaîne formatée :[prefix] #[count]: [message]GetCount() int- renvoie le nombre total de messages enregistrés
main.go: démontrez que plusieurs appels àGetLogger()renvoient la même instance.Lisez une nouvelle valeur de préfixe, puis lisez un nombre de messages suivi de chaque message à enregistrer.
Récupérez l’instance du logger, définissez le préfixe personnalisé, puis enregistrez chaque message et affichez le résultat. Après avoir enregistré tous les messages, récupérez à nouveau l’instance du logger (pour prouver qu’il s’agit de la même) et affichez le nombre total de messages.
Les entrées suivantes seront fournies :
- Ligne 1 : préfixe personnalisé à définir
- Ligne 2 : nombre de messages
- Lignes suivantes : chaque message à enregistrer
Par exemple, avec :
[APP]
3
Server started
User connected
Request processedVotre sortie doit être :
[APP] #1: Server started
[APP] #2: User connected
[APP] #3: Request processed
Total messages logged: 3Et avec :
[DEBUG]
2
Initializing cache
Cache readyVotre sortie doit être :
[DEBUG] #1: Initializing cache
[DEBUG] #2: Cache ready
Total messages logged: 2Et avec :
[ERROR]
1
Connection failedVotre sortie doit être :
[ERROR] #1: Connection failed
Total messages logged: 1L’idée essentielle est que, quel que soit le nombre de fois où vous appelez GetLogger(), vous obtenez toujours la même instance avec son état partagé. Le nombre de messages persiste, car il n’existe qu’un seul Logger !
Essayez vous-même
package main
import (
"bufio"
"fmt"
"os"
"strconv"
"strings"
)
func main() {
reader := bufio.NewReader(os.Stdin)
// Lire le préfixe personnalisé
prefix, _ := reader.ReadString('\n')
prefix = strings.TrimSpace(prefix)
// Lire le nombre de messages
countStr, _ := reader.ReadString('\n')
countStr = strings.TrimSpace(countStr)
count, _ := strconv.Atoi(countStr)
// Lire chaque message
messages := make([]string, count)
for i := 0; i < count; i++ {
msg, _ := reader.ReadString('\n')
messages[i] = strings.TrimSpace(msg)
}
// TODO: Obtenir l'instance du logger en utilisant GetLogger()
// TODO: Définir le préfixe personnalisé en utilisant SetPrefix()
// TODO: Logger chaque message et afficher le résultat
// TODO: Obtenir à nouveau l'instance du logger (pour prouver que c'est la même)
// and print the total message count in format: "Total messages logged: X"
}
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érique13Design Patterns – Partie 1
Introduction aux Design PatternsPattern SingletonPattern FactoryPattern Abstract FactoryPattern ObserverPattern Strategy2Plongé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