héritage et intérêt des interfaces

Pour aller au bout de mon exemple :
Mon agent possède actuellement un plugin pour les bases SQL Server et un pour MySQL.

Si un jour quelqu'un veut que mon agent puisse se connecter à une base Oracle, j'ai juste à coder la classe correspondante et ajouter sa dll dans mon dossier de plugin; tout le reste se fera tout seul sans rien changer dans le code de mon agent :D

Citation:

---

Oui c'est ça l'idée ^^ dans mon cas l'interface est réellement indispensable car je ne connais pas mes classes à la compilation; elles ne sont présentes qu'au moment de l'exécution.

---

En fait, dans ton programme principal, tu utilises un objet plugin de type IOdbcLink qui est implémenté par toutes les classes associées à un type de connexion (sql server, mysql...).

ok, et comme tu utilises cet objet de type "générique" (et que tous les objets qui implémentent cette interface implémentent les méthodes de l'interface) ton programme n'est pas à modifier en cas d'ajout d'un nouveau type de connexion...

ok ok ok...

C'est bien plus clair et concret !

Un très grand merci pour le temps que vous m'avez tous accordé !

je pense que t'as pigé :ccool:

Je pense qu'on s'est tous demandé l'utilité des interfaces la première fois qu'on nous les a présentées :P

Personnellement, je n'ai vraiment compris que quand j'ai dû les mettre en oeuvre de cette manière; avant mes professeurs m'avaient simplement dit que c'était des "coquilles vides" qui obligeaient des classes à avoir des méthodes; ça ne m'avait vraiment pas aidée :weird: :mrgreen:

oui, c'est également ce qui est écrit dans le bouquin que je potasse :
une demi page pour dire que toutes les interfaces sont des coquilles dans lesquelles on ne donne que le prototype des méthodes que doivent implémenter les classes qui implémente l'interface...

c'est vachement léger par rapport aux possibilité que ça offre !

2 mots clé très utile dans l'utilisation des interfaces is et as.

is pour savoir si ta classe implémente l'interface (renvoie true si elle l'implémente).
as pour caster ton objet en tant que ton interface (si ton objet ne l'implémente pas il te retournera null).

Exemple:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

// Avec is private void Do(objet monObjet) { if(monObjet is IVivant) { IVivant monEtre=(IVivant)monObjet; monEtre.Do(); .... } }   // Avec as private void Do(objet monObjet) { IVivant monEtre=monObjet as IVivant;   if(monEtre!=null) { monEtre.Do(); .... } }

---

Petit corollaire...

Dans l'exemple IVivant, serait-il possible d'écrire un programme principal qui crée un objet générique IVivant (je ne crois pas qu'il soit possible d'instancier une interface) et d'appeler monObjet.Nourir() ?

L'idée serait de ne pas modifier le programme puis d'ajouter la classe Ours...

J'ai tenté, mais je bloque sur la création d'un objet générique (qui retournerait true à is IVivant)...

Auriez-vous une idée ?

Merci (encore et encore et encore :-) )

Effectivement, il n'est pas possible de créer un IVivant.
Si tu étais dieu et que tu devais créer "quelque chose qui sait vivre", il faudrait que tu décides du type concret (homme, ourse, poisson, etc). L'interface c'est le "quelque chose qui sait..." sauf qu'on ne connait pas le quelque chose.

Généralement, ca n'est pas le programme qui créé directement l'instance, on passe plutot par une Factory (qui elle connait toutes les implémentations de l'interface). Exemple, je passe une maman ours et un papa ours à ma Factory et ca me donne un ourson. Tu as donné ce qu'il fallait pour créer un ours mais tu as délégué le rôle une partie qui sait le faire car toi finalement, dans ton programme ca ne t'intéresse pas.

tu ne peux pas instancier une interface (comme une classe abstraite):

Code:

---

1 2 3 4 5 6

// Tu ne peux pas faire ça IVivant etreVivant=new IVivant();   // Mais tu peux faire ça IVivant etreVivant=new Humain();

---

dans ton code de génération des strings de connexion aux bd, l'équivalent à :

Code:

---

1 2	// Mais tu peux faire ça IVivant etreVivant=new Humain();

---

est :

Code:

---

1 2 3

IOdbcLink plugin = m_TemplistOfOdbcPlugin.Find( delegate(IOdbcPlugin pluginSearch) { return pluginSearch.GetDatabaseType() == dbType ;});

---

c'est ça ?

Citation:

---

Envoyé par grinder59

dans ton code de génération des strings de connexion aux bd, l'équivalent à :

Code:

---

1 2	// Mais tu peux faire ça IVivant etreVivant=new Humain();

---

est :

Code:

---

1 2 3

IOdbcLink plugin = m_TemplistOfOdbcPlugin.Find( delegate(IOdbcPlugin pluginSearch) { return pluginSearch.GetDatabaseType() == dbType ;});

---

c'est ça ?

---

Tout à fait :P

merci encore à tous pour votre aide qui me montre que le chemin vers la maîtrise de C# est longue et ardue !

Des questions se posent toutefois : comment est-il possible dans le bouquin que je potasse (http://www.amazon.fr/Net-Versions-%C.../dp/2212126042) que cet aspect des interfaces ne soit pas évoqué et que le bouquin ne fasse que l'effleurer ?

Y'a-t-il d'autres points du même genre qui ne sont que théoriquement abordés dans les ouvrages de référence alors qu'ils permettent concrètement d'aller très loin dans la flexibilité du développement réalisé ?

Citation:

---

Y'a-t-il d'autres points du même genre qui ne sont que théoriquement abordés dans les ouvrages de référence alors qu'ils permettent concrètement d'aller très loin dans la flexibilité du développement réalisé ?

---

Surement mais ça on s'en rend compte quand quelqu'un de compétent nous l'explique ou qu'on y est confronté.

Oui, je pense que la maitrise d'un langage c'est grosso modo 30% de théorie (au début surtout :aie:) et 70% de pratique.

Enfin, pour moi "pratique" =
apprendre un nouvel élément
le tester
se vautrer
chercher une solution
trouver
réessayer
apprendre un nouvel élément
le tester
se vautrer ... :mrgreen:

On apprend de ses erreurs, mais souvent dans le dev', c'est une erreur par jour, mais jamais la même ;)