Christian Hubert-Hugoud / weabow - Xtrem7 - Groobax
Bonjour,
J'ai une appli qui utilise une dll. Depuis cette appli, je souhaite utiliser
des Interfaces pour créer des objets, fournis par la dll.
Cela fonctionne tant que la classe qui hérite de l'Interface est publique
(dans la dll).
Or, si cette classe est publique, je peux instancier directement un objet en
utilisant la classe, et non pas l'Interface.
Or je souhaite que les utilisateurs qui utilisent la dll n'aient pas accès à
la classe elle-même. Je voudrais que la classe soit cachée.
Est-ce possible ?
Voici le code :
La classe qui est dans la dll :
namespace Xtrem7Engine
{
public class X7login : IX7login
{
public string GetFullVersion()
{
return "Coucou";
}
}
}
L'interface de cette classe (dans la dll aussi) :
namespace Xtrem7Engine
{
public interface IX7login
{
string GetFullVersion();
}
}
L'appel depuis l'appli :
private void button1_Click(object sender, RoutedEventArgs e)
{
Xtrem7Engine.IX7login Login;
Login = new Xtrem7Engine.IX7login();
MessageBox.Show(Login.GetFullVersion());
}
or on peut aussi très bien faire :
private void button1_Click(object sender, RoutedEventArgs e)
{
Xtrem7Engine.X7login Login;
Login = new Xtrem7Engine.X7login();
MessageBox.Show(Login.GetFullVersion());
}
Dans ce second cas, on utilise la classe directement.
Christian Hubert-Hugoud / weabow - Xtrem7 - Groobax
Je comprends bien.
Je comprends aussi que l'Interface est une sorte de couche de sécurité supplémentaire, nommée contrat. Pourquoi pas. Néanmoins, comme tu le soulignes, la classe peut faire exactement la même chose, à condition que le développeur soit vigilant à ne pas la faire évoluer, dans ses relations avec l'extérieur.
Merci à toi
"Christophe Lephay" a écrit dans le message de news:4b654bfc$0$17522$
"Christian Hubert-Hugoud / weabow - Xtrem7 - Groobax" a écrit dans le message de groupe de discussion :
Je n'ai pas d'intention, si ce n'est de comprendre comment cela fonctionne. Effectivement je ne vois pas l'intérêt.
Pour comprendre comment cela fonctionne, ça aide de savoir à quoi ça sert.
A mon sens, une interface sert à deux choses :
- éviter les références croisées .net ne propose pas un modèle de compilation séparée comme en C++, dans lequel on sépare déclaration et implémentation. De ce fait, si une classe A utilise une classe B qui, elle-même, utilise la classe A, on ne peut pas compiler à moins de baser l'une ou l'autre (ou préférablement les deux) sur des interfaces définies dans des assemblies différents des deux classes A et B.
- un contrat distribué Pour tout le monde, une interface définit un contrat. Dans le cadre d'une infrastructure distribuée, le compilateur ne peut pas avoir accès au code ni aux données présents sur un processus (et possiblement une machine) différent. Si, dans l'absolu, une classe de base représente aussi un contrat, l'interface est le contrat maximum que peut garantir le compilateur dans un environnement distribué.
Je comprends bien.
Je comprends aussi que l'Interface est une sorte de couche de sécurité
supplémentaire, nommée contrat. Pourquoi pas. Néanmoins, comme tu le
soulignes, la classe peut faire exactement la même chose, à condition que le
développeur soit vigilant à ne pas la faire évoluer, dans ses relations avec
l'extérieur.
Merci à toi
"Christophe Lephay" <christophe-lephay@wanadoo.fr> a écrit dans le message
de news:4b654bfc$0$17522$ba4acef3@news.orange.fr...
"Christian Hubert-Hugoud / weabow - Xtrem7 - Groobax" <nospam@weabow.com>
a écrit dans le message de groupe de discussion :
OZX2ARAoKHA.4628@TK2MSFTNGP06.phx.gbl...
Je n'ai pas d'intention, si ce n'est de comprendre comment cela
fonctionne. Effectivement je ne vois pas l'intérêt.
Pour comprendre comment cela fonctionne, ça aide de savoir à quoi ça sert.
A mon sens, une interface sert à deux choses :
- éviter les références croisées
.net ne propose pas un modèle de compilation séparée comme en C++, dans
lequel on sépare déclaration et implémentation.
De ce fait, si une classe A utilise une classe B qui, elle-même, utilise
la classe A, on ne peut pas compiler à moins de baser l'une ou l'autre (ou
préférablement les deux) sur des interfaces définies dans des assemblies
différents des deux classes A et B.
- un contrat distribué
Pour tout le monde, une interface définit un contrat. Dans le cadre d'une
infrastructure distribuée, le compilateur ne peut pas avoir accès au code
ni aux données présents sur un processus (et possiblement une machine)
différent. Si, dans l'absolu, une classe de base représente aussi un
contrat, l'interface est le contrat maximum que peut garantir le
compilateur dans un environnement distribué.
Je comprends aussi que l'Interface est une sorte de couche de sécurité supplémentaire, nommée contrat. Pourquoi pas. Néanmoins, comme tu le soulignes, la classe peut faire exactement la même chose, à condition que le développeur soit vigilant à ne pas la faire évoluer, dans ses relations avec l'extérieur.
Merci à toi
"Christophe Lephay" a écrit dans le message de news:4b654bfc$0$17522$
"Christian Hubert-Hugoud / weabow - Xtrem7 - Groobax" a écrit dans le message de groupe de discussion :
Je n'ai pas d'intention, si ce n'est de comprendre comment cela fonctionne. Effectivement je ne vois pas l'intérêt.
Pour comprendre comment cela fonctionne, ça aide de savoir à quoi ça sert.
A mon sens, une interface sert à deux choses :
- éviter les références croisées .net ne propose pas un modèle de compilation séparée comme en C++, dans lequel on sépare déclaration et implémentation. De ce fait, si une classe A utilise une classe B qui, elle-même, utilise la classe A, on ne peut pas compiler à moins de baser l'une ou l'autre (ou préférablement les deux) sur des interfaces définies dans des assemblies différents des deux classes A et B.
- un contrat distribué Pour tout le monde, une interface définit un contrat. Dans le cadre d'une infrastructure distribuée, le compilateur ne peut pas avoir accès au code ni aux données présents sur un processus (et possiblement une machine) différent. Si, dans l'absolu, une classe de base représente aussi un contrat, l'interface est le contrat maximum que peut garantir le compilateur dans un environnement distribué.
Patrice
> Je comprends aussi que l'Interface est une sorte de couche de sécurité supplémentaire, nommée contrat. Pourquoi pas. Néanmoins, comme tu le soulignes, la classe peut faire exactement la même chose, à condition que le développeur soit vigilant à ne pas la faire évoluer, dans ses relations avec l'extérieur.
Bonjour,
Un petit détail mais l'intérêt de l'interface est aussi qu'elle va pouvoir être implémentée par autant de classes que nécessaire.
L'exemple assez classique est un mécanisme d'add-in. L'interface permet d'indiquer quel est le contrat qui va être utilisé mais il pourra y avoir autant d'addin (de classes) que nécessaire qui vont implanter ce contract...
Le rôle d'une interface est donc à mon avis un peu plus à valoriser que cela (ce n'est pas une simple amélioration d'une classe mais cela apporte aussi des caractéristiques uniques)...
-- Patrice
> Je comprends aussi que l'Interface est une sorte de couche de sécurité
supplémentaire, nommée contrat. Pourquoi pas. Néanmoins, comme tu le
soulignes, la classe peut faire exactement la même chose, à condition que
le développeur soit vigilant à ne pas la faire évoluer, dans ses relations
avec l'extérieur.
Bonjour,
Un petit détail mais l'intérêt de l'interface est aussi qu'elle va pouvoir
être implémentée par autant de classes que nécessaire.
L'exemple assez classique est un mécanisme d'add-in. L'interface permet
d'indiquer quel est le contrat qui va être utilisé mais il pourra y avoir
autant d'addin (de classes) que nécessaire qui vont implanter ce contract...
Le rôle d'une interface est donc à mon avis un peu plus à valoriser que cela
(ce n'est pas une simple amélioration d'une classe mais cela apporte aussi
des caractéristiques uniques)...
> Je comprends aussi que l'Interface est une sorte de couche de sécurité supplémentaire, nommée contrat. Pourquoi pas. Néanmoins, comme tu le soulignes, la classe peut faire exactement la même chose, à condition que le développeur soit vigilant à ne pas la faire évoluer, dans ses relations avec l'extérieur.
Bonjour,
Un petit détail mais l'intérêt de l'interface est aussi qu'elle va pouvoir être implémentée par autant de classes que nécessaire.
L'exemple assez classique est un mécanisme d'add-in. L'interface permet d'indiquer quel est le contrat qui va être utilisé mais il pourra y avoir autant d'addin (de classes) que nécessaire qui vont implanter ce contract...
Le rôle d'une interface est donc à mon avis un peu plus à valoriser que cela (ce n'est pas une simple amélioration d'une classe mais cela apporte aussi des caractéristiques uniques)...
-- Patrice
Christian Hubert-Hugoud / weabow - Xtrem7 - Groobax
Merci de ce recadrage
"Patrice" <http://scribe-fr.blogspot.com/> a écrit dans le message de news:
Je comprends aussi que l'Interface est une sorte de couche de sécurité supplémentaire, nommée contrat. Pourquoi pas. Néanmoins, comme tu le soulignes, la classe peut faire exactement la même chose, à condition que le développeur soit vigilant à ne pas la faire évoluer, dans ses relations avec l'extérieur.
Bonjour,
Un petit détail mais l'intérêt de l'interface est aussi qu'elle va pouvoir être implémentée par autant de classes que nécessaire.
L'exemple assez classique est un mécanisme d'add-in. L'interface permet d'indiquer quel est le contrat qui va être utilisé mais il pourra y avoir autant d'addin (de classes) que nécessaire qui vont implanter ce contract...
Le rôle d'une interface est donc à mon avis un peu plus à valoriser que cela (ce n'est pas une simple amélioration d'une classe mais cela apporte aussi des caractéristiques uniques)...
-- Patrice
Merci de ce recadrage
"Patrice" <http://scribe-fr.blogspot.com/> a écrit dans le message de
news:evIVqr0oKHA.3748@TK2MSFTNGP02.phx.gbl...
Je comprends aussi que l'Interface est une sorte de couche de sécurité
supplémentaire, nommée contrat. Pourquoi pas. Néanmoins, comme tu le
soulignes, la classe peut faire exactement la même chose, à condition que
le développeur soit vigilant à ne pas la faire évoluer, dans ses
relations avec l'extérieur.
Bonjour,
Un petit détail mais l'intérêt de l'interface est aussi qu'elle va pouvoir
être implémentée par autant de classes que nécessaire.
L'exemple assez classique est un mécanisme d'add-in. L'interface permet
d'indiquer quel est le contrat qui va être utilisé mais il pourra y avoir
autant d'addin (de classes) que nécessaire qui vont implanter ce
contract...
Le rôle d'une interface est donc à mon avis un peu plus à valoriser que
cela (ce n'est pas une simple amélioration d'une classe mais cela apporte
aussi des caractéristiques uniques)...
"Patrice" <http://scribe-fr.blogspot.com/> a écrit dans le message de news:
Je comprends aussi que l'Interface est une sorte de couche de sécurité supplémentaire, nommée contrat. Pourquoi pas. Néanmoins, comme tu le soulignes, la classe peut faire exactement la même chose, à condition que le développeur soit vigilant à ne pas la faire évoluer, dans ses relations avec l'extérieur.
Bonjour,
Un petit détail mais l'intérêt de l'interface est aussi qu'elle va pouvoir être implémentée par autant de classes que nécessaire.
L'exemple assez classique est un mécanisme d'add-in. L'interface permet d'indiquer quel est le contrat qui va être utilisé mais il pourra y avoir autant d'addin (de classes) que nécessaire qui vont implanter ce contract...
Le rôle d'une interface est donc à mon avis un peu plus à valoriser que cela (ce n'est pas une simple amélioration d'une classe mais cela apporte aussi des caractéristiques uniques)...
-- Patrice
Christophe Lephay
"Patrice" <http://scribe-fr.blogspot.com/> a écrit dans le message de groupe de discussion :
Un petit détail mais l'intérêt de l'interface est aussi qu'elle va pouvoir être implémentée par autant de classes que nécessaire.
L'exemple assez classique est un mécanisme d'add-in. L'interface permet d'indiquer quel est le contrat qui va être utilisé mais il pourra y avoir autant d'addin (de classes) que nécessaire qui vont implanter ce contract...
Le rôle d'une interface est donc à mon avis un peu plus à valoriser que cela (ce n'est pas une simple amélioration d'une classe mais cela apporte aussi des caractéristiques uniques)...
Une classe de base peut aussi avoir autant de classes dérivées que nécessaire.
En revanche, dans un modèle ne supportant pas l'héritage multiple, on ne peut pas avoir plusieurs classes de base.
Si c'est de cette "amélioration" dont tu parles, à savoir la possibilité d'implémenter plusieurs interfaces, elle ne fait selon moi que donner des béquilles à un unijambiste. De ce fait, j'ai du mal à concevoir les interfaces en terme d'amélioration.
J'avoue n'avoir toujours pas bien compris pourquoi .net ne supportait pas l'héritage multiple.
"Patrice" <http://scribe-fr.blogspot.com/> a écrit dans le message de groupe
de discussion : evIVqr0oKHA.3748@TK2MSFTNGP02.phx.gbl...
Un petit détail mais l'intérêt de l'interface est aussi qu'elle va pouvoir
être implémentée par autant de classes que nécessaire.
L'exemple assez classique est un mécanisme d'add-in. L'interface permet
d'indiquer quel est le contrat qui va être utilisé mais il pourra y avoir
autant d'addin (de classes) que nécessaire qui vont implanter ce
contract...
Le rôle d'une interface est donc à mon avis un peu plus à valoriser que
cela (ce n'est pas une simple amélioration d'une classe mais cela apporte
aussi des caractéristiques uniques)...
Une classe de base peut aussi avoir autant de classes dérivées que
nécessaire.
En revanche, dans un modèle ne supportant pas l'héritage multiple, on ne
peut pas avoir plusieurs classes de base.
Si c'est de cette "amélioration" dont tu parles, à savoir la possibilité
d'implémenter plusieurs interfaces, elle ne fait selon moi que donner des
béquilles à un unijambiste. De ce fait, j'ai du mal à concevoir les
interfaces en terme d'amélioration.
J'avoue n'avoir toujours pas bien compris pourquoi .net ne supportait pas
l'héritage multiple.
"Patrice" <http://scribe-fr.blogspot.com/> a écrit dans le message de groupe de discussion :
Un petit détail mais l'intérêt de l'interface est aussi qu'elle va pouvoir être implémentée par autant de classes que nécessaire.
L'exemple assez classique est un mécanisme d'add-in. L'interface permet d'indiquer quel est le contrat qui va être utilisé mais il pourra y avoir autant d'addin (de classes) que nécessaire qui vont implanter ce contract...
Le rôle d'une interface est donc à mon avis un peu plus à valoriser que cela (ce n'est pas une simple amélioration d'une classe mais cela apporte aussi des caractéristiques uniques)...
Une classe de base peut aussi avoir autant de classes dérivées que nécessaire.
En revanche, dans un modèle ne supportant pas l'héritage multiple, on ne peut pas avoir plusieurs classes de base.
Si c'est de cette "amélioration" dont tu parles, à savoir la possibilité d'implémenter plusieurs interfaces, elle ne fait selon moi que donner des béquilles à un unijambiste. De ce fait, j'ai du mal à concevoir les interfaces en terme d'amélioration.
J'avoue n'avoir toujours pas bien compris pourquoi .net ne supportait pas l'héritage multiple.
Jérémy Jeanson
Bonjour Tout le monde,
Ça philosophe dans les newsgroups ;)
@ Christophe : Je rebondi sur ton interrogation:
J'avoue n'avoir toujours pas bien compris pourquoi .net ne supportait pas l'héritage multiple.
A mon avis il s'agit juste de soucis de sécurité... porté des varaibles bien souvant mal métrisée par els développeurs. Imagine donc une classe avec plusieurs variables internes du même nom et qui soient protected... boooooom!
L'héritage simple : on peut faire bon nombre de choses. Les interfaces : chacun son avis (moi j'aime surtout avace la généricité de .net 2 et Linq de .net 3.5) Les classes Abstract c'est sympa, mais j'en utilise de moins en moins. Ajouter à ça que l'on a 2 tonnes de patterns, .net c'est la fête ;)
--- Jérémy JEANSON MCP http://www.jjeanson.fr
Bonjour Tout le monde,
Ça philosophe dans les newsgroups ;)
@ Christophe : Je rebondi sur ton interrogation:
J'avoue n'avoir toujours pas bien compris pourquoi .net ne supportait pas
l'héritage multiple.
A mon avis il s'agit juste de soucis de sécurité... porté des
varaibles bien souvant mal métrisée par els développeurs.
Imagine donc une classe avec plusieurs variables internes du même nom
et qui soient protected... boooooom!
L'héritage simple : on peut faire bon nombre de choses.
Les interfaces : chacun son avis (moi j'aime surtout avace la
généricité de .net 2 et Linq de .net 3.5)
Les classes Abstract c'est sympa, mais j'en utilise de moins en moins.
Ajouter à ça que l'on a 2 tonnes de patterns, .net c'est la fête ;)
J'avoue n'avoir toujours pas bien compris pourquoi .net ne supportait pas l'héritage multiple.
A mon avis il s'agit juste de soucis de sécurité... porté des varaibles bien souvant mal métrisée par els développeurs. Imagine donc une classe avec plusieurs variables internes du même nom et qui soient protected... boooooom!
L'héritage simple : on peut faire bon nombre de choses. Les interfaces : chacun son avis (moi j'aime surtout avace la généricité de .net 2 et Linq de .net 3.5) Les classes Abstract c'est sympa, mais j'en utilise de moins en moins. Ajouter à ça que l'on a 2 tonnes de patterns, .net c'est la fête ;)
--- Jérémy JEANSON MCP http://www.jjeanson.fr
Christophe Lephay
"Jérémy Jeanson" a écrit dans le message de groupe de discussion :
Ça philosophe dans les newsgroups ;)
;)
@ Christophe : Je rebondi sur ton interrogation:
J'avoue n'avoir toujours pas bien compris pourquoi .net ne supportait pas l'héritage multiple.
A mon avis il s'agit juste de soucis de sécurité... porté des varaibles bien souvant mal métrisée par els développeurs. Imagine donc une classe avec plusieurs variables internes du même nom et qui soient protected... boooooom!
C'est un peu ce genre de trucs que je m'étais dit, en particulier concernant l'héritage en diamant dans lequel on peut hériter plusieurs fois d'une même classe de base.
Pourtant, le même soucis existe avec les interface, qui a été géré avec les implémentations explicites.
"Jérémy Jeanson" <jeremy.jeanson@free.fr> a écrit dans le message de groupe
de discussion :
20ea3dcc-1601-47d8-a95e-0cbaa8c9f62e@n7g2000yqb.googlegroups.com...
Ça philosophe dans les newsgroups ;)
;)
@ Christophe : Je rebondi sur ton interrogation:
J'avoue n'avoir toujours pas bien compris pourquoi .net ne supportait pas
l'héritage multiple.
A mon avis il s'agit juste de soucis de sécurité... porté des
varaibles bien souvant mal métrisée par els développeurs.
Imagine donc une classe avec plusieurs variables internes du même nom
et qui soient protected... boooooom!
C'est un peu ce genre de trucs que je m'étais dit, en particulier concernant
l'héritage en diamant dans lequel on peut hériter plusieurs fois d'une même
classe de base.
Pourtant, le même soucis existe avec les interface, qui a été géré avec les
implémentations explicites.
"Jérémy Jeanson" a écrit dans le message de groupe de discussion :
Ça philosophe dans les newsgroups ;)
;)
@ Christophe : Je rebondi sur ton interrogation:
J'avoue n'avoir toujours pas bien compris pourquoi .net ne supportait pas l'héritage multiple.
A mon avis il s'agit juste de soucis de sécurité... porté des varaibles bien souvant mal métrisée par els développeurs. Imagine donc une classe avec plusieurs variables internes du même nom et qui soient protected... boooooom!
C'est un peu ce genre de trucs que je m'étais dit, en particulier concernant l'héritage en diamant dans lequel on peut hériter plusieurs fois d'une même classe de base.
Pourtant, le même soucis existe avec les interface, qui a été géré avec les implémentations explicites.
