paramétre avec type dynamique ?
Salut à tous,
je bloque sur le point suivant :
j'ai un object qui me permet de manipuler une BDD via une connexion Odbc :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
public class HelperOdbc {
public void ConnectStringBuilder()
{
//construction du connnectionString
}
public DataSet SelectQuery(string myQuery, string myTable)
{
//open connection
//requetage qui renvoie un dataset
}
....
} |
maintenant je dois rajouter dans mes dev une possibilité de se connecter en Oledb,
je refais donc une autre class sur le même modèle que la précédente :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
public class HelperOledb {
public void ConnectStringBuilder()
{
//construction du connnectionString
}
public DataSet SelectQuery(string myQuery, string myTable)
{
//open connection
//requetage qui renvoie un dataset
}
...
} |
et je comptais faire une troisième class qui me permet de renvoyer une instance de l'une des 2 class précédentes,
suivant la méthode de connexion choisie (oledb / odbc)
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
public class HelperBdd {
public ??? connectionHelper
public HelperBdd
{
switch (connectionType)
{
case "oledb":
this.connectionHelper = new HelperOledb();
break;
case "odbc":
this.connectionHelper = new HelperOdbc();
break;
}
} |
comment faire pour que HelperBdd.connectionHelper soit d'un type HelperOdbc OU HelperOledb?
ou alors c'est mon approche qui est mauvaise?
D'avance, merci.
ça marche très bien aussi
j'ai modifier les sources comme tu m'avais indiqué, et effectivement ça marche super bien.
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
|
public interface IHelperBdd
{
void ConnectStringBuilder();
DataSet SelectQuery(string myQuery, string myTable);
}
public class FactoryBdd
{
public IHelperBdd getConnection(string type)
{
switch (type)
{
case "oledb":
return new HelperOledb();
case "odbc":
return new HelperOdbc();
default:
throw new Exception("Invalid type of Bdd connection");
}
}
}
public class HelperOledbInterface : IHelperBdd
{
public void ConnectStringBuilder()
{
//construction du connnectionString
}
public DataSet SelectQuery(string myQuery, string myTable)
{
//open connection
//requetage qui renvoie un dataset
}
}
public class HelperOdbcInterface : IHelperBdd
{
public void ConnectStringBuilder()
{
//construction du connnectionString
}
public DataSet SelectQuery(string myQuery, string myTable)
{
//open connection
//requetage qui renvoie un dataset
}
} |
La vrai ruse c'est la methode FactoryBdd.getConnection() qui est de type IHelperBdd, et qui peut retourner une instance d'une class qui "hérite" de l'interface IHelperBdd !
J'étais pas prés de trouver ça tout seul.
par contre, j'ai un peu potassé et je vois pas bien en quoi, la solution avec l'interface est plus "élégante/adaptée" que celle avec la class abstract?
il y a notamment la page suivante : Abstract Classes vs. Interfaces
qui liste quelques recommandations sur l'utilisation de Abstract vs Interface :
- If you anticipate creating multiple versions of your component, create an abstract class. Abstract classes provide a simple and easy way to version your components. By updating the base class, all inheriting classes are automatically updated with the change. Interfaces, on the other hand, cannot be changed once created. If a new version of an interface is required, you must create a whole new interface.
- If the functionality you are creating will be useful across a wide range of disparate objects, use an interface. Abstract classes should be used primarily for objects that are closely related, whereas interfaces are best suited for providing common functionality to unrelated classes.
- If you are designing small, concise bits of functionality, use interfaces. If you are designing large functional units, use an abstract class.
- If you want to provide common, implemented functionality among all implementations of your component, use an abstract class. Abstract classes allow you to partially implement your class, whereas interfaces contain no implementation for any members.
les points 2 et 4, semblent faire pencher la balance vers la class abstract, mais peut-être que je me gourre.
quoiqu'il en soit, merci beaucoup, ça m'a bien éclairé sur l'utilisation des class abstraites et des interfaces.
@++
