Avec quels modèles de conception êtes-vous familier…

Je suis familiarisé avec divers modèles de conception utilisés en Go. Certains des plus courants:

Patrons de création:

Singleton: Assure qu'une seule instance d'une classe existe et fournit un point d'accès global à celle-ci. En Go, cela est souvent réalisé avec sync.Once.

package main

import (
	"sync"
)

type singleton struct{}

var instance *singleton
var once sync.Once

func GetInstance() *singleton {
	once.Do(func() {
		instance = &singleton{}
	})
	return instance
}

Factory Method: Définit une interface pour créer un objet, mais permet aux sous-classes de décider quelle classe instancier. En Go, cela est souvent réalisé avec des fonctions retournant une interface.

package main

type Product interface {
	Operate()
}

type ConcreteProductA struct{}

func (p *ConcreteProductA) Operate() {
	// Implémentation de l'opération
}

type ConcreteProductB struct{}

func (p *ConcreteProductB) Operate() {
	// Implémentation de l'opération
}

func NewProduct(productType string) Product {
	switch productType {
	case "A":
		return &ConcreteProductA{}
	case "B":
		return &ConcreteProductB{}
	default:
		return nil // Ou erreur
	}
}

Abstract Factory: Fournit une interface pour créer des familles d'objets liés ou dépendants sans spécifier leurs classes concrètes.
Builder: Sépare le processus de construction d'un objet complexe de sa représentation.

Patrons structurels:

Adapter: Convertit l'interface d'une classe en une autre que les clients attendent. Permet à des classes incompatibles de travailler ensemble.
Decorator: Ajoute dynamiquement des responsabilités à un objet. Les décorateurs offrent une alternative flexible à l'héritage pour étendre la fonctionnalité.
Facade: Fournit une interface unifiée à un ensemble d'interfaces dans un sous-système. Définit une interface de haut niveau qui facilite l'utilisation du sous-système.
Proxy: Fournit un substitut ou un représentant pour un autre objet pour contrôler l'accès à celui-ci.

Patrons comportementaux:

Observer: Définit une dépendance de "un à plusieurs" entre objets. Lorsqu'un objet change d'état, tous ses dépendants sont notifiés et mis à jour automatiquement.

Strategy: Définit une famille d'algorithmes, encapsule chacun d'eux et les rend interchangeables. Permet aux algorithmes de varier indépendamment des clients qui les utilisent.

package main

type Strategy interface {
	Execute(data string)
}

type ConcreteStrategyA struct{}

func (s *ConcreteStrategyA) Execute(data string) {
	// Implémentation de la stratégie A
}

type ConcreteStrategyB struct{}

func (s *ConcreteStrategyB) Execute(data string) {
	// Implémentation de la stratégie B
}

type Context struct {
	strategy Strategy
}

func (c *Context) SetStrategy(strategy Strategy) {
	c.strategy = strategy
}

func (c *Context) ExecuteStrategy(data string) {
	c.strategy.Execute(data)
}

Template Method: Définit la structure d'un algorithme dans une opération, laissant certains pas aux sous-classes. Permet aux sous-classes de redéfinir certains étapes d'un algorithme sans changer sa structure.

En plus des modèles mentionnés, je connais également des modèles tels que Command, Chain of Responsibility, Iterator, Mediator, Memento, State, Visitor. En Go, on utilise aussi fréquemment des idiomes de conception spécifiques au langage, comme l'utilisation d'interfaces pour l'abstraction, des goroutines et des canaux pour la concurrence.

Avec quels modèles de conception êtes-vous familier?