Discussion :

[mrqs2crbs]

Salut à tous,

je bloque sur le point suivant :

j'ai un object qui me permet de manipuler une BDD via une connexion Odbc :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

[ebastien]

Bonjour,
La solution passe par de l'héritage. Un truc du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
53
54
55
56
57
58
public abstract class HelperDb
    {
        public abstract void ConnectStringBuilder();
        public abstract DataSet SelectQuery(string myQuery, string myTable);
 
    }
 
    public class HelperOdbc : HelperDb
    {
 
        public override void ConnectStringBuilder()
        {
            //construction du connnectionString
        }
 
        public override DataSet SelectQuery(string myQuery, string myTable)
        {
            //open connection 
            //requetage qui renvoie un dataset 
            return null;
        }
    }
 
 
    public class HelperOledb : HelperDb
    {
 
        public override void ConnectStringBuilder()
        {
            //construction du connnectionString
        }
 
        public override DataSet SelectQuery(string myQuery, string myTable)
        {
            //open connection 
            //requetage qui renvoie un dataset 
            return null;
        }
 
    }
 
    public class FactoryBd
    {
        public HelperDb getConnection(string type)
        {
            switch (type)
            {
                case "oleDb":
                    return new HelperOledb();
 
                case "odbc":
                    return new HelperOdbc();
 
                default:
                    throw new Exception("Invalid db");
            }
        }
    }

(Il y avait des boulettes dans mon code, je viens de corriger)

[mrqs2crbs]

Merci ebastien,

ça marche nickel!

j'ai plus qu'à me documenter sur les class et methods abstract.

@++

[ebastien]

Je pense à une autre solution plus élégante qui serait de passer par une interface (c'est quasi équivalent à une classe abstraite pure mais avec plus de souplesse)
Le code serait quasi identique mais à la place de définir une classe abstraite, tu définis une interface et la factory retournerait cette interface.
Avantage : Une classe peut implémenter plusieurs interfaces (alors que l'héritage multiple est interdit en dotnet) et peut en plus hériter d'une classe de base,
Inconvénient : Une classe de base permet aussi mutualiser du code, pas une interface.

Bon c'était pour chipoter un peu...

[ericlm128]

Le plus approprié pour son cas semble l'interface.

[mrqs2crbs]

j'ai modifier les sources comme tu m'avais indiqué, et effectivement ça marche super bien.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 :

1. 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.
2. 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.
3. If you are designing small, concise bits of functionality, use interfaces. If you are designing large functional units, use an abstract class.
4. 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.

@++

[ericlm128]

Vu que ta classe de base ne contient pas de code c'est une interface.
Dans ton cas, ce que tu souhaite c'est que tes 2 classes possèdent 2 méthodes ayant la même signature.

Interface
Je pense donc que tu souhaite que tes 2 classes implémentent ces méthodes.

Class astraite
Tu ne souhaite pas vraiment que tes 2 classes ressemblent à une autre, ou hérite de méthode ou propriété que tu n'aurai pas à réécrire.
Il n'y à pas de factorisation de code.

Je ne suis peut être pas très clair ...
http://blog.clever-age.com/fr/2006/0...une-interface/
http://www.developpez.net/forums/d13...traite-csharp/
http://www.dotnetdojo.com/interfaces...es-abstraites/

[mrqs2crbs]

non, non, c'est très clair:

si il y a une class de base qui possède déjà du code, on utilise une class abstract.

s'il n'y a pas de code à factoriser, on utilise une interface.

merci pour les explications,
je vais lire les liens.