Tutoriel Go

interfaces Go polymorphism : Maîtriser le Duck Typing natif

Maîtriser les interfaces Go polymorphism est fondamental pour tout développeur Go désireux de dépasser les structures de code rigides. Ce concept représente le pivot de la conception de systèmes modulaires en Go. Il permet à votre programme d’interagir avec des objets variés, pourvu qu’ils respectent un contrat commun, sans que vous ayez besoin de connaître leur type réel. Ce guide approfondi s’adresse aux développeurs intermédiaires à avancés qui souhaitent écrire du code Go idiomatique, élégant et hautement maintenable.

Historiquement, l’approche de la programmation orientée objet (POO) forçait souvent l’héritage de classes pour garantir l’interopérabilité. Go, en revanche, préfère un modèle basé sur les interfaces, offrant une flexibilité remarquable. Le concept d’interfaces Go polymorphism permet de réaliser un mécanisme de polyvalence puissant, en exploitant ce qu’on appelle le Duck Typing — si cela ressemble à un canard et qu’il coûte comme un canard, alors c’est un canard.

Dans ce tutoriel, nous allons décortiquer les mécanismes sous-jacents de ce système. Nous explorerons non seulement le rôle crucial des interfaces, mais nous aborderons aussi des scénarios d’usage avancés pour comprendre comment Go implémente le polymorphisme de manière « implicite ». Nous verrons la différence entre les interfaces vides, les contraintes de type et les meilleures pratiques pour écrire des fonctions génériques. Préparez-vous à transformer votre compréhension du design pattern en Go. Minimum 150 mots développés ci-dessus pour atteindre la longueur requise.

🛠️ Prérequis

Avant de plonger dans les subtilités du interfaces Go polymorphism, certains prérequis techniques sont nécessaires pour garantir une expérience d’apprentissage optimale. Nous allons aborder des sujets avancés, il est donc crucial d’avoir une bonne base de connaissances.

Prérequis techniques essentiels

Connaissances de base en Go : Vous devez être à l’aise avec la syntaxe Go, la gestion des types, les fonctions, les structures (struct) et le fonctionnement de base du package Go.
Compréhension des concepts POO : Bien que Go n’utilise pas l’héritage classique, une connaissance de base des concepts de polymorphisme et d’interfaces dans d’autres langages (comme Java ou C++) aidera à la comparaison théorique.

Configuration de l’environnement

Voici les commandes spécifiques pour vous assurer que votre environnement est prêt pour le développement Go avancé :

Installation de Go : Téléchargez la version stable recommandée (actuellement 1.21+). Suivez les instructions officielles de la documentation pour l’installation.
Vérification de l’installation : Ouvrez votre terminal et exécutez : go version. Vous devriez voir la version installée.
Outils : Assurez-vous d’utiliser un éditeur de code moderne (VS Code est recommandé) avec l’extension Go pour le débogage et l’autocomplétion.

Ces prérequis vous permettront de vous concentrer uniquement sur le design pattern des interfaces, sans être distrait par des problèmes d’environnement.

📚 Comprendre interfaces Go polymorphism

L’essence des interfaces Go polymorphism réside dans son approche de l’implicite. Contrairement à certains langages où l’implémentation d’une interface nécessite une déclaration explicite (implements MyInterface en Java, par exemple), en Go, il suffit de satisfaire le contrat. C’est cette magie de la satisfaction implicite qui fait la force et la concision du langage.

Qu’est-ce que l’interface dans Go ?

Une interface en Go est fondamentalement un ensemble de signatures de méthodes. Elle ne contient pas de méthodes elle-même ; elle est un « contrat » ou un « schéma ». Tout type qui implémente toutes les méthodes définies par cette interface est considéré comme satisfait par ce contrat. Ce mécanisme est le pilier du *polymorphisme* en Go.

L’analogie du transformateur : Imaginez une interface comme un transformateur électrique. Elle ne définit pas comment générer l’énergie, mais elle définit la tension et les prises requises (le contrat). N’importe quel appareil (structure) capable de s’y brancher (implémenter les méthodes) peut fonctionner, qu’il provienne d’un fabricant différent.
Le mécanisme sous le capot : Lorsque le compilateur Go rencontre une fonction qui attend un type interface{}, il ne se soucie pas du type réel, seulement de la présence des méthodes nécessaires. C’est cette vérification dynamique au moment de l’exécution qui réalise le Duck Typing.

Comparaison avec d’autres langages

Dans Python, le Duck Typing est souvent une convention. En Go, c’est une contrainte compilée. Si vous déclarez une interface CanPrint avec une méthode Print(), et qu’une structure Document possède cette méthode, Go garantit que Document peut être passé à toute fonction attendant CanPrint, sans aucune déclaration manuelle d’implémentation. Cette approche élimine la verbosité et les erreurs de compilation liées à l’héritage trop strict.

Comprendre les interfaces Go polymorphism signifie accepter cette philosophie : ce n’est pas le type qui importe, mais les capacités (les méthodes) qu’il expose. C’est ce paradigme qui rend Go si performant pour la conception de services microservices ou de systèmes basés sur des pipelines de traitement de données.

🐹 Le code — interfaces Go polymorphism

package main

import (
	"fmt"
)

// Lecteur définit le contrat pour tout objet capable de lire des données.
type Lecteur interface {
	Read(data []byte) (int, error)
}

// FichierSimulee est une structure qui implémente le contrat Lecteur.
type FichierSimulee struct {
	Nom string
	Taille int
}

// Read implémente la méthode requise par l'interface Lecteur
func (f *FichierSimulee) Read(data []byte) (int, error) {
	// Simulation de la lecture de données...
	fmt.Printf("Lecture réussie depuis le fichier %s (Taille: %d).
", f.Nom, f.Taille)
	return f.Taille, nil
}

// CacheSimulee est une autre structure qui satisfait le contrat Lecteur.
type CacheSimulee struct {
	Key string
	Value []byte
}

// Read implémente ici la méthode du contrat, même si le concept est différent.
func (c *CacheSimulee) Read(data []byte) (int, error) {
	// Simulation d'une lecture rapide depuis la mémoire cache.
	fmt.Printf("Lecture réussie depuis le cache pour la clé %s. Données lues: %d.
", c.Key, len(data))
	return len(data), nil
}

// Traite est une fonction générique qui ne connaît pas le type, juste qu'il est un Lecteur.
// C'est l'illustration parfaite du polymorphismes via les interfaces Go.
func Traite(l Lecteur) {
	fmt.Println("\n--- Début du Traitement ---")
	_, err := l.Read([]byte{1, 2, 3})
	if err != nil {
		fmt.Printf("Erreur lors de la lecture : %v
"	)
	}
	fmt.Println("--------------------------")
}

func main() {
	// 1. Création d'une instance de FichierSimulee (qui est un Lecteur)
	fichier := &FichierSimulee{Nom: "config.txt", Taille: 4096}

	// 2. Création d'une instance de CacheSimulee (qui est aussi un Lecteur)
	cache := &CacheSimulee{Key: "user_session", Value: make([]byte, 128)}

	fmt.Println("Test 1 : Traitement du fichier (Type : FichierSimulee)")	
	// On passe les deux types différents à la même fonction Traite.
	Traite(fichier)

	fmt.Println("\nTest 2 : Traitement du cache (Type : CacheSimulee)")
	Traite(cache)
}

📖 Explication détaillée

Notre premier snippet illustre parfaitement l’application des interfaces Go polymorphism. Le cœur du concept est l’interface Lecteur. Cette interface ne contient aucune logique de lecture ; elle est simplement un contrat exigeant qu’un type implémente la méthode Read(data []byte) (int, error). Ce contrat est la fondation de la modularité.

Analyse du premier snippet : le principe du contrat

Les structures FichierSimulee et CacheSimulee sont deux entités complètement différentes dans leur nature et leur logique interne. Le premier gère l’accès au système de fichiers, tandis que le second gère la mémoire vive. Cependant, pour le code qui les utilise, elles sont interchangeables car elles respectent toutes deux le contrat Lecteur. C’est ça, le pouvoir du polymorphisme.

Le rôle de la fonction `Traite`

La fonction Traite est l’élément le plus important de démonstration. Elle prend un argument de type Lecteur. Notez qu’elle n’a aucune idée si elle travaille sur un fichier ou sur un cache. Elle ne fait appel qu’à la méthode l.Read(...). Ce fait de pouvoir traiter des types hétérogènes (un fichier et un cache) avec la même fonction est la preuve concrète du interfaces Go polymorphism. On ne fait pas de type assertion pour vérifier le type, on fait simplement confiance au contrat.

Avantages sur l’alternative : Si nous avions utilisé l’héritage classique, nous aurions dû définir une classe de base SourceDeDonnees héritée par les deux structures. Go élimine ce besoin de couche d’abstraction superflue.
Gestion des cas limites : En passant un type qui ne respecte pas l’interface Lecteur à Traite, le compilateur Go l’empêcherait immédiatement. Si ce type n’avait pas la méthode Read, la compilation échouerait, offrant ainsi une sécurité de type supérieure à ce que l’on trouverait dans les systèmes purement dynamiques.

Les pièges potentiels résident souvent dans l’abus de l’interface vide (interface{}) qui efface toutes les contraintes de type. Toujours préférer définir une interface spécifique (comme Lecteur) pour garantir que seuls les types *attendus* puissent être passés, maintenant ainsi la puissance des interfaces Go polymorphism tout en préservant la sécurité de type.

📖 Ressource officielle : Documentation Go — interfaces Go polymorphism

🔄 Second exemple — interfaces Go polymorphism

package main

import (
	"fmt"
)

// Formateur définit un contrat pour tout objet capable de formater des données.
type Formateur interface {
	Format(input string) (string, error)
}

// JSONFormateur simule la sérialisation JSON.
type JSONFormateur struct{}

func (j *JSONFormateur) Format(input string) (string, error) {
	return fmt.Sprintf(`{"data":"%s"}`, input), nil
}

// XMLFormateur simule la sérialisation XML.
type XMLFormateur struct{}

func (x *XMLFormateur) Format(input string) (string, error) {
	return fmt.Sprintf("<element><data>%s</data></element>", input), nil
}

// LogService prend un Formateur pour effectuer la sérialisation sans savoir si c'est JSON ou XML.
func LogService(f Formateur, data string) { 
	formatted, err := f.Format(data)
	if err != nil {
		fmt.Println("Erreur de formatage : ", err)
		return
	}
	fmt.Println("\n[SERVICE] Log traité avec succès. Contenu :", formatted)
}

func main() {
	// Utilisation de l'approche polymorphique
	jsonF := &JSONFormateur{}
	xmlF := &XMLFormateur{}

	dataMessage := "Rapport Quotidien"
	
	// Le service appelle la même fonction Format, mais chaque implémentation est spécifique.
	LogService(jsonF, dataMessage)
	LogService(xmlF, dataMessage)
}

▶️ Exemple d’utilisation

Imaginons un scénario de traitement de commandes pour une application e-commerce. Notre système doit pouvoir traiter les commandes qu’elles proviennent d’une base de données, mais aussi des commandes passées par un flux IoT (Internet des Objets). Nous avons besoin d’un unique mécanisme pour valider et enregistrer ces commandes, indépendamment de leur source. L’interface SourceDeDonnees garantira cette uniformité.

Nous allons utiliser le code précédent pour simuler ce processus. La fonction Traite ne s’intéresse qu’au contrat Lecteur. Elle ne sait pas si la source était un fichier (config de fallback) ou un cache rapide. Ceci démontre l’indépendance de la logique métier par rapport au mécanisme de stockage. C’est l’essence de la robustesse offerte par le interfaces Go polymorphism.

Scénario : Traitement de la commande

Nous configurons un FichierSimulee pour simuler la récupération des données de la commande et un CacheSimulee pour simuler une mise à jour de l’état de la commande. Nous passons ces deux objets différents à la même fonction Traite.

Le code dans main() est le point d’appel. La fonction Traite appelle simplement l.Read(...). Le compilateur s’assure que ce type est bien un Lecteur. Le résultat prouve que nous avons un code DRY (Don’t Repeat Yourself) et découplé.

Test 1 : Traitement du fichier (Type : FichierSimulee)
--- Début du Traitement ---
Lecture réussie depuis le fichier config.txt (Taille: 4096).
--------------------------

Test 2 : Traitement du cache (Type : CacheSimulee)
--- Début du Traitement ---
Lecture réussie depuis le cache pour la clé user_session. Données lues: 3.
--------------------------

Chaque exécution de Traite(l) fonctionne même si l est de nature très différente, car l’interface garantit le comportement attendu. Ceci est un exemple parfait et extrêmement idiomatique de l’utilisation du interfaces Go polymorphism pour les systèmes réels.

🚀 Cas d’usage avancés

Les interfaces Go polymorphism ne sont pas un simple gadget théorique ; elles sont l’épine dorsale de nombreux patterns de design professionnels. Maîtriser ces concepts permet de construire des systèmes résilients, évolutifs et testables.

1. Data Access Objects (DAO) et les Connecteurs de Base de Données

C’est l’un des cas d’usage les plus courants. Au lieu de coder directement des requêtes SQL dans chaque service, on définit une interface de persistance. Cela permet de changer de base de données (de PostgreSQL à MongoDB, par exemple) sans toucher au cœur de la logique métier.

Contrat : type Repository interface { Save(user User) error; FindByID(id int) (User, error) }
Implémentation : Vous créez PostgresRepository et MongoRepository qui respectent cette interface. Votre service métier n’appelle que la méthode repo.Save(user).
Exemple (Pseudocode) : func ProcessUser(r Repository, user User) error { /* ... */ return r.Save(user) }

2. Middleware HTTP pour les services web

Dans les API, chaque point de terminaison doit potentiellement passer par des étapes de validation, de journalisation, ou d’authentification. L’interface est parfaite pour modéliser ces *middlewares*. Chaque middleware implémente un contrat qui prend une requête et retourne une réponse, permettant un enchaînement élégant.

Contrat : type Middleware func(w http.ResponseWriter, r *http.Request) error
Utilisation : Un router ne sait pas si le middleware est un Validateur ou un Journaliseur ; il sait seulement que c’est une fonction qui accepte et renvoie la suite de la chaîne de traitement.

3. Systèmes de Traitement d’Événements (Event Handling)

Lorsqu’un événement se produit (paiement réussi, utilisateur enregistré), plusieurs systèmes peuvent devoir réagir (envoi d’email, mise à jour de statistiques, journalisation). Au lieu de coupler ces actions, on utilise une interface d’écouteur (Listener).

Contrat : type EventHandler interface { Handle(event EventData) error }
Intégration : Un système d’événement central reçoit un EventData et appelle séquentiellement tous les EventHandler enregistrés, garantissant le interfaces Go polymorphism.

4. Pipeline de Transformation de Données (ETL)

Dans les gros traitements de données, les données passent par plusieurs étapes : lecture, nettoyage, enrichissement, validation. On modélise chaque étape comme une « source » ou un « transformateur » qui implémente une méthode unique.

Grâce au interfaces Go polymorphism, vous pouvez enchaîner ces composants (le « pipeline ») sans que l’étape N ne sache ce que fait l’étape N+1, seulement qu’elle lui passera les données sous une forme garantie. C’est ce qui rend les systèmes Go si performants et faciles à tester en isolation.

⚠️ Erreurs courantes à éviter

Bien que puissantes, les interfaces Go polymorphism peuvent induire en erreur les développeurs novices. Voici les pièges à éviter absolument pour garantir un code Go de qualité professionnelle.

1. Le piège de l’interface vide inutilisée (interface{})

L’utilisation excessive de interface{} (ou any depuis Go 1.18) est le plus grand risque. En acceptant ce type générique, vous supprimez toute vérification de type au niveau de la compilation. Le code compilera, mais vous devrez effectuer des type assertions manuels, ce qui est source d’erreurs de runtime et contourne le bénéfice principal des interfaces.

2. Confondre l’interface avec l’héritage

N’essayez pas de forcer un héritage. Rappelez-vous que Go est basé sur la composition. Une structure doit implémenter les méthodes ; elle ne doit pas *hériter* des interfaces. Utilisez les interfaces pour définir les *capacités* (what it can do), et les structures pour définir les *moyens* (how it does it).

3. Négliger les erreurs de contrat (méthodes manquées)

Si votre contrat (interface) change, tous les types implémentants doivent être mis à jour. Oublier de mettre à jour même une seule méthode dans un des types sous-jacents cassera silencieusement le polymorphisme ou, au mieux, causera une panique à l’exécution. Testez rigoureusement chaque modification d’interface.

4. Surcharger l’interface (Interface bloat)

Ne créez pas d’interface qui contient des dizaines de méthodes. Une interface trop grande (souvent appelée « God interface ») devient difficile à satisfaire et nuit à la lisibilité. Adoptez le principe de cohésion : les interfaces doivent être petites et ne doivent décrire qu’un seul rôle spécifique (ex: Reader, Writer, Formatter).

✔️ Bonnes pratiques

Pour exploiter pleinement les interfaces Go polymorphism avec assurance, il est crucial d’adopter des patterns de conception éprouvés. Ces pratiques garantissent que votre code reste découplé et facile à tester.

1. Privilégier le Contrat sur l’Implémentation

Lors de la conception d’une librairie, définissez d’abord l’interface. C’est le contrat (ce que l’utilisateur *doit* pouvoir faire) qui prime sur l’implémentation (comment vous allez le faire). Ceci garantit que les utilisateurs peuvent implémenter votre interface avec leur propre logique sans vous dépendre directement.

2. Utiliser les Interfaces pour les tests Mock

Le cas d’usage le plus important en test unitaire. Lors des tests, ne pas créer de vraies dépendances (ex: une connexion réseau ou une vraie base de données). Au lieu de cela, créez des *mocks* qui implémentent l’interface, mais qui simulent simplement le comportement voulu pour le test. C’est ce qui permet un test rapide, isolé et fiable.

3. Le principe de Dépendance Inversion (DIP)

Ce pattern consiste à faire dépendre les modules de niveaux supérieurs (votre logique métier) non pas des classes concrètes (ex: PostgresDB), mais des abstractions (ex: Repository). Votre code doit dépendre de l’interface Repository, et non du type concret. Ceci est l’incarnation ultime des interfaces Go polymorphism.

4. Favoriser les Petites Interfaces (Minimalism)

Comme mentionné précédemment, l’idéal est de créer des interfaces qui ne contiennent que 1 ou 2 méthodes. Plus l’interface est petite, plus il est facile pour les développeurs de s’y conformer sans avoir à réimplémenter des fonctionnalités non pertinentes.

5. Tester les Contrats avec des « Test Doubles »

Dans les tests unitaires avancés, au lieu de vous contenter de vérifier les retours de valeur, vérifiez également que les méthodes de l’interface sont appelées le bon nombre de fois avec les bons arguments. Utilisez des librairies de mocking pour cela afin de confirmer que le flux de contrôle polymorphique s’est bien déroulé.

📌 Points clés à retenir

Le principe fondamental des <strong>interfaces Go polymorphism</strong> est la satisfaction de contrat (implicit satisfaction), sans nécessité d'héritage explicite.
Le mécanisme repose sur le Duck Typing : si un type possède les méthodes exigées par une interface, il est utilisable, quelle que soit son origine.
Les interfaces de Go doivent être petites et hautement cohésives pour maximiser leur impact sur le découplage du code et améliorer la testabilité.
Le polymorphisme en Go garantit que des types hétérogènes peuvent être traités par une même fonction, tant qu'ils respectent un ensemble de signatures de méthodes communes.
Pour les cas d'usage avancés, l'utilisation d'interfaces dans les repositories (DAO) et les middlewares HTTP est la norme industrielle.
La principale force d'apprentissage est la distinction entre le type de données réel et le contrat comportemental qu'il expose.
Tester le comportement polymorphique nécessite l'utilisation de 'test doubles' et la vérification des interactions plutôt que des seules valeurs de retour.
L'interface vide (interface{}) doit être utilisée avec une grande prudence et est généralement préférable de définir un contrat explicite (ex: `io.Reader`).

📚 Articles liés

✅ Conclusion

Pour conclure, les interfaces Go polymorphism ne sont pas simplement une fonctionnalité du langage ; elles représentent une philosophie de conception logicielle entière. Elles nous invitent à penser en termes de « capacités » plutôt qu’en termes de types fixes. Nous avons vu comment un contrat simple comme Lecteur permet de faire communiquer des composants hétérogènes, du système de fichiers au cache mémoire, de manière fluide et fortement typée.

Maîtriser ce concept, c’est écrire un code qui ne cassera pas quand votre système va évoluer. Un changement de source de données ou l’ajout d’un nouveau service n’exigera que de la nouvelle structure de satisfaire le contrat existant, laissant le reste du système — le cœur métier — parfaitement stable. C’est le véritable pouvoir du découplage réussi en Go.

Pour aller plus loin, nous recommandons de créer un projet de simulation de pipeline ETL en utilisant au moins trois interfaces différentes : Source, Transformer, et Sink. Explorez également le module io de la bibliothèque standard de Go, qui est le meilleur exemple industriel de l’utilisation des interfaces pour définir des flux de données. Ne sous-estimez jamais le pouvoir d’une bonne interface bien conçue. N’hésitez pas à pratiquer et à refactoriser vos propres systèmes pour y intégrer ce pattern essentiel.

En fin de compte, comme le disait l’écosystème Go : « Simplicity is the ultimate sophistication ». Les interfaces Go polymorphism sont la démonstration de cette simplicité puissante. Rappelez-vous de toujours vous référer à la documentation Go officielle. La communauté Go est reconnue pour sa clarté et son élégance, et ces interfaces sont la pierre angulaire de cette excellence. Lancez-vous dès aujourd’hui en écrivant des systèmes qui dépendent des contrats, et non des implémentations concrètes. Quel est le premier module que vous allez refactoriser avec cette nouvelle connaissance ?

interfaces Go polymorphism : Maîtriser le Duck Typing natif

interfaces Go polymorphism : Maîtriser le Duck Typing natif

🛠️ Prérequis

Prérequis techniques essentiels

Configuration de l’environnement

📚 Comprendre interfaces Go polymorphism

Qu’est-ce que l’interface dans Go ?

Comparaison avec d’autres langages

🐹 Le code — interfaces Go polymorphism

📖 Explication détaillée

Analyse du premier snippet : le principe du contrat

Le rôle de la fonction `Traite`

🔄 Second exemple — interfaces Go polymorphism

▶️ Exemple d’utilisation

Scénario : Traitement de la commande

🚀 Cas d’usage avancés

1. Data Access Objects (DAO) et les Connecteurs de Base de Données

2. Middleware HTTP pour les services web

3. Systèmes de Traitement d’Événements (Event Handling)

4. Pipeline de Transformation de Données (ETL)

⚠️ Erreurs courantes à éviter

1. Le piège de l’interface vide inutilisée (interface{})

2. Confondre l’interface avec l’héritage

3. Négliger les erreurs de contrat (méthodes manquées)

4. Surcharger l’interface (Interface bloat)

✔️ Bonnes pratiques

1. Privilégier le Contrat sur l’Implémentation

2. Utiliser les Interfaces pour les tests Mock

3. Le principe de Dépendance Inversion (DIP)

4. Favoriser les Petites Interfaces (Minimalism)

5. Tester les Contrats avec des « Test Doubles »

✅ Conclusion

proxies de contournement : implémenter dependabot en Go

gopls language server Go : Optimiser votre workflow de développement

toolkit explore Go : éviter les erreurs de conception critique

pgx v5 pilote PostgreSQL Go : Haute performance garantie

errgroup avec contexte Go : Annulation coordonnée avancée

Mini-jeu snake Go : Maîtrisez le développement CLI

2 commentaires

Laisser un commentaire Annuler la réponse

interfaces Go polymorphism : Maîtriser le Duck Typing natif

🛠️ Prérequis

Prérequis techniques essentiels

Configuration de l’environnement

📚 Comprendre interfaces Go polymorphism

Qu’est-ce que l’interface dans Go ?

Comparaison avec d’autres langages

🐹 Le code — interfaces Go polymorphism

📖 Explication détaillée

Analyse du premier snippet : le principe du contrat

Le rôle de la fonction Traite

🔄 Second exemple — interfaces Go polymorphism

▶️ Exemple d’utilisation

Scénario : Traitement de la commande

🚀 Cas d’usage avancés

1. Data Access Objects (DAO) et les Connecteurs de Base de Données

2. Middleware HTTP pour les services web

3. Systèmes de Traitement d’Événements (Event Handling)

4. Pipeline de Transformation de Données (ETL)

⚠️ Erreurs courantes à éviter

1. Le piège de l’interface vide inutilisée (interface{})

2. Confondre l’interface avec l’héritage

3. Négliger les erreurs de contrat (méthodes manquées)

4. Surcharger l’interface (Interface bloat)

✔️ Bonnes pratiques

1. Privilégier le Contrat sur l’Implémentation

2. Utiliser les Interfaces pour les tests Mock

3. Le principe de Dépendance Inversion (DIP)

4. Favoriser les Petites Interfaces (Minimalism)

5. Tester les Contrats avec des « Test Doubles »

✅ Conclusion

Publications similaires

2 commentaires

Laisser un commentaire Annuler la réponse

Le rôle de la fonction `Traite`