Dictionnaire à 2 clef

**anthyme** · 29/01/2009, 16h59

Et oui je reviens avec mes idées bizarres

J'aimerai savoir si il existe une implémentation d'un dictionnaire à 2 clef.
en gros on ferait dict.Get("clef1", "clef2") et dict.Set("clef1","clef2", value)

En gros le but serai d'avoir la représentation d'un tableau ou chaque colone serai associé a une des premières clef (dans mon cas une date) et chaque ligne associé une des deuxièmes clef (un objet business) et donc chaque cellule contient une valeur correspondant avec une des premières et une des deuxièmes clef (un peu comme des coordonnées)

Comment représenter cela efficacement ? (et pas de datatable non typé hein !

)

Merci

**dev01** · 30/01/2009, 12h07

Envoyé par anthyme

Et oui je reviens avec mes idées bizarres

J'aimerai savoir si il existe une implémentation d'un dictionnaire à 2 clef.
en gros on ferait dict.Get("clef1", "clef2") et dict.Set("clef1","clef2", value)

En gros le but serai d'avoir la représentation d'un tableau ou chaque colone serai associé a une des premières clef (dans mon cas une date) et chaque ligne associé une des deuxièmes clef (un objet business) et donc chaque cellule contient une valeur correspondant avec une des premières et une des deuxièmes clef (un peu comme des coordonnées)

Comment représenter cela efficacement ? (et pas de datatable non typé hein !

)

Merci

Deux solutions : Soit tu écrit ta classe de gestion de grille (type excel) soit tu utilises un Dictionnary<int, Dictionnary<int, object>>

**anthyme** · 30/01/2009, 15h05

Mouarf !

Bon je vais réfléchir la dessus mais bon mes collègues me poussent a faire une datatable ... moi qui espérait sortir une solution de mon chapeau magique

Merci pour les idées !

**B.AF** · 16/02/2009, 08h56

Tiens, moi j'utilise ça; ca prends moins de temps qu'une table, c'est plus léger;

J'arrive en moyenne à faire du 100*1000000.

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
59
60
61
62
63
64
65
66
67
68
69
 
public class CompositeKeyDictionary<T,U,V> 
    {
        private Dictionary<T, Dictionary<U, V>> _grid;
 
        public CompositeKeyDictionary()
        {
            _grid = new Dictionary<T, Dictionary<U, V>>();
 
        }
 
        public IEnumerable<V> GetThirdLevel(T k1)
        {
            if (_grid.ContainsKey(k1))
            {
                return _grid[k1].Values;
            }
            return null;
        }
 
        public IDictionary<U,V> GetRecords(T k1)
        {
            if (_grid.ContainsKey(k1))
            {
                return _grid[k1];
            }
            return null;
        }
 
        public void ClearRecords(T k1)
        {
            if (_grid.ContainsKey(k1))
            {
                _grid[k1].Clear();
            }
        }
 
        public void AddRecord(T k1,U k2,V k3)
        {
            Dictionary<U, V> kvp;
            if (_grid.ContainsKey(k1))
            {
                kvp = _grid[k1];
                kvp.Add(k2, k3);
 
            }
            else
            {
                kvp = new Dictionary<U, V>();
                kvp.Add(k2, k3);
                _grid.Add(k1, kvp);
 
            }
 
        }
 
        public void RemoveRecord(T k1)
        {
            _grid.Remove(k1);
        }
 
        public void Clear()
        {
            _grid.Clear();
        }
 
 
 
    }

**Guulh** · 16/02/2009, 12h25

Si tu n'as besoin que des cellules et jamais des lignes / colonnes, un dico simple suffit :

Code :

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

Dictionary<Pair<string, string>, T>

Où Pair est une struct toute bête à deux valeurs (le fx 3.5 a probablement ça quelque part), qui doit même pas avoir besoin de surcharger IEquatable parce qu'il me semble déjà que deux structs sont égales si tous ses champs sont égaux.

**B.AF** · 16/02/2009, 12h47

Non, c'est un peu lourd à faire en fait si tu veux une structure relationnelle.

En fait tu es obligé de créer tes propres critéres de comparaison.

Au début j'avais utilisé un objet<T,U> qui recevait deux params et constitue la clef, mais au bout d'un moment, si tu encapsules ça dans un objet, tu vas arriver au moment où tu vas faire un truc genre :

Code :

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

1
2
3
4
5
6
7
8
9

var _busobject=(BusinessObject)ObjectFactory.GetBusinessObject(25);
var _assertion=new CompositeKey<DateTime,BusinessObject>(DateTime.Parse("01/01/2008"),_busobject);

if (_dic.contains(_assertion))
{
...
}

Et là, tu es obligé de spécifier une modalité de comparaison de la clef pour un couple donné.

J'avais à l'époque utilisé le moteur d'évaluation de spring et une instanciation par string[] des propriétés à contrôler, mais là, ça devient beaucoup trop lours à traiter en fait.

**Guulh** · 16/02/2009, 13h01

Bah si tu fais un héritage ou que tu encapsules, comme suggéré dans le post initial, avec deux méthodes get et set du style dict.Get("clef1", "clef2") et dict.Set("clef1","clef2", value), je vois pas le souci. La verbosioté est masquée dans ces deux méthodes.

**smyley** · 16/02/2009, 13h24

Code c# :

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
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
 
public class CompositKey<T, K> : IEquatable<CompositKey<T, K>> where T:IEquatable<T> where K:IEquatable<K>
        {
            public CompositKey(T key1, K key2)
            {
                Key1 = key1;
                Key2 = key2;
 
                if (Key1 == null || Key2 == null)
                    throw new ArgumentNullException(Key1 == null ? "Key1" : "Key2");
            }
 
            public virtual T Key1 { get; protected set; }
            public virtual K Key2 { get; protected set; }
 
            public override int GetHashCode()
            {
                return (int)(Key1.GetHashCode() + Key2.GetHashCode());
            }
 
            #region IEquatable<CompositKey<T,K>> Membres
 
            public bool Equals(CompositKey<T, K> other)
            {
                if (ReferenceEquals(other,null))
                    return false;
                else
                {
                    bool c1, c2;
 
                    if (Key1 == null)
                        c1 = other.Key1 == null;
                    else
                        c1 = Key1.Equals(other.Key1);
 
                    if (Key2 == null)
                        c2 = other.Key2 == null;
                    else
                        c2 = Key2.Equals(other.Key2);
 
                    return c1 && c2;
                }
            }
 
            #endregion
 
            public static bool operator ==(CompositKey<T, K> a, CompositKey<T, K> b)
            {
                if (ReferenceEquals(a, null))
                    return ReferenceEquals(b, null);
                else
                    return a.Equals(b);
            }
 
            public static bool operator !=(CompositKey<T, K> a, CompositKey<T, K> b)
            {
                if (ReferenceEquals(a, null))
                    return !ReferenceEquals(b, null);
                else
                    return !a.Equals(b);
            }
        }
 
        /* ET LE TEST !! */
        public Form1()
        {
            Dictionary<CompositKey<string, string>, string> test 
                = new Dictionary<CompositKey<string, string>, string>();
            test[new CompositKey<string, string>("A", "B")] = "chat";
            test[new CompositKey<string, string>("A", "C")] = "chien";
 
            var gh = new CompositKey<string, string>("A", "C");
            MessageBox.Show(gh.Equals(new CompositKey<string, string>("A", "C")).ToString());
            MessageBox.Show((gh == (new CompositKey<string, string>("A", "C"))).ToString());
 
            MessageBox.Show(test.ContainsKey(new CompositKey<string, string>("A", "B")).ToString());
            MessageBox.Show(test.ContainsKey(new CompositKey<string, string>("A", "C")).ToString());
            MessageBox.Show(test.ContainsKey(new CompositKey<string, string>("D", "B")).ToString());
 
            MessageBox.Show(test[new CompositKey<string, string>("A", "B")]);
       }

J'ai juste un doute : il se passe quoi si deux clefs ont le même Hash ?
edit: ah non c'est bon. S'il y a collision des HashCode, la méthode Equals est appelée donc ça marche bien.

**Guulh** · 16/02/2009, 14h08

C'est un peu too much, non, une classe pour stocker deux champs, constants qui plus est ?

Et il me semble que les structs ont automatiquement un Equals et un GetHashCode qui prennent en compte tous les champs qu'elles contiennent.

Une struct CompositKey se résume alors à ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public struct CompositKey<T, K> : IEquatable<CompositKey<T, K>>
{
  public CompositKey(T key1, K key2)
  {
    Key1 = key1;
    Key2 = key2;
  }
  public T Key1 { get; private set; }
  public K Key2 { get; private set; }
  public bool Equals(CompositKey<T, K> other)
  {
    return this == other;
  }
}

Pas testé mais ça devrait marcher. Et faire moins mal au GC

**smyley** · 16/02/2009, 14h19

Ton code marche pas

Et c'est pas vraiment too much si tu retires les override pour les opérateurs == et != (c'est juste un effet pour pouvoir comparer deux clefs sans se casser la tête avec ==)

Après le code marche. C'est sur que si on crée beaucoup de clefs ça pourrai faire le GC râler mais vu la taille d'une clef (en gros une dizaine d'octets) ça restera négligeable.

Pour la struct j'y avais pas pensé, mais bon, ça revient un peut au même (vu qu'on ne va pas avoir souvent à écrire le code de CompositKey : c'est une classe dans un coin dont tout ce que l'on va savoir c'est que ça s'écrit CompositKey<T,K>).

**Gold Bug** · 16/02/2009, 14h43

Envoyé par Guulh

Et il me semble que les structs ont automatiquement un Equals et un GetHashCode qui prennent en compte tous les champs qu'elles contiennent.

T'es certain de ça ?

Parce que si c'est vrai, je pense que je vais transformer ma classe CompositeKey "maison" par une struct

**B.AF** · 16/02/2009, 15h01

Je connais déjà la réponse.

En plus, vive les stack overflows...

**Gold Bug** · 16/02/2009, 15h18

Envoyé par B.AF

Je connais déjà la réponse.

En plus, vive les stack overflows...

Heu, non pas franchement. J'ai récemment du me développer une classe MyFieldKey pour utiliser des dictionnaires de MyField parce que j'ai 2 niveau de clé : un string et un entier, mais je trouve ma construction super lourde (j'ai été obligé de redéfinir les méthodes Equals() et GetHashCode(), ce qui ne me plaît pas trop) donc je cherche comment la changer, c'est pour ça que je suis ce fil de discussion avec intérêt.

**Guulh** · 16/02/2009, 15h46

Envoyé par Gold Bug

T'es certain de ça ?

Code :

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

1
2
3
4
5
6
7
8
9
struct Bidule { public int I, J; }
 
void f()
{
  Bidule b1 = new Bidule();
  Bidule b2 = new Bidule(); // ici, b1.Equals(b2) est true
  b1.I = 5; // b1.Equals(b2) est false
  b2.I = 5; // b1.Equals(b2) est true
}

Donc oui, pas besoin de surcharger Equals. Là où je me suis gourré, c'est que l'operator== est pas défini par défaut, et qu'il faut le surcharger s'il on veut s'en servir.

smyley : oui c'est pas bien important, mais les pauvres structs sont utiles dans si peu de cas qu'il faut pas leur retirer leurs quelques instants de gloire

**Gold Bug** · 16/02/2009, 15h52

Envoyé par Guulh

Code :

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

1
2
3
4
5
6
7
8
9
struct Bidule { public int I, J; }
 
void f()
{
  Bidule b1 = new Bidule();
  Bidule b2 = new Bidule(); // ici, b1.Equals(b2) est true
  b1.I = 5; // b1.Equals(b2) est false
  b2.I = 5; // b1.Equals(b2) est true
}

Donc oui, pas besoin de surcharger Equals. Là où je me suis gourré, c'est que l'operator== est pas défini par défaut, et qu'il faut le surcharger s'il on veut s'en servir.

smyley : oui c'est pas bien important, mais les pauvres structs sont utiles dans si peu de cas qu'il faut pas leur retirer leurs quelques instants de gloire

Ca marche pareil si J est de type String ?