Problème de conception : héritage VS composition VS… séparation

Version imprimable

Bonjour,
Comme dit dans le titre, j'ai un petit problème de conception.
Enfin c'est plus une interrogation qu'un problème, mais bon...

En fait, j'ai un couple de valeurs, avec une sémantique précise.
Pour certains cas, j'aimerais augmenter ce couple avec une troisième valeur.
La sémantique du couple restant la même, mais avec la nouvelle valeur le tout devient un triplet à part entière.

D'où la seconde partie de la question dans le titre.
Alors à votre avis, 1, 2 ou 3 ?

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
53
54
55
class couple
{
 
  public:
    typedef ... first_type;
    typedef ... second_type;
 
  private:
    first_type m_first;
    second_type m_second;
 
  public:
    couple() = default;
 
    couple(first_type const& e1, second_type const& e2) : m_first(e1), m_second(e2)
    {}
 
    first_type const& get_first() const
    { return m_first; }
 
    second_type const& get_second() const
    { return m_second; }
 
    void get(first_type& e1, second_type& e2) const
    {
        e1 = m_first;
        e2 = m_second;
    }
 
    void reset()
    {
        m_first = first_type();
        m_second = second_type();
    }
 
    void set(first_type const& e1, second_type const& e2)
    {
        m_first = e1;
        m_second = e2;
    }
 
}; // class couple
 
 
bool operator == (couple const& lhs, couple const& rhs)
{
    return ( (lhs.get_first() == rhs.get_first()) && (lhs.get_second() == rhs.get_second()) );
}
 
 
bool operator < (couple const& lhs, couple const& rhs)
{
    return ( (lhs.get_first() < rhs.get_first()) ||
           ( (lhs.get_first() == rhs.get_first()) && (lhs.get_second() < rhs.get_second()) ));
}

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
53
54
55
56
57
58
59
60
61
62
63
64
65
66
class triplet : private couple
{
 
  public:
    typedef couple::first_type first_type;
    typedef couple::second_type second_type;
    typedef ... third_type;
 
  private:
    third_type m_third;
 
  public:
    triplet() = default;
 
    triplet(first_type const& e1, second_type const& e2, third_type const& e3) : couple(e1, e2), m_third(e3)
    {}
 
    using couple::get_first;
 
    using couple::get_second;
 
    third_type const& get_third() const
    { return m_third; }
 
    void get(first_type& e1, second_type& e2, third_type& e3) const
    {
        couple::get(e1, e2);
        e3 = m_third;
    }
 
    void reset()
    {
        couple::reset();
        m_third = third_type();
    }
 
    void set(first_type const& e1, second_type const& e2, third_type const& e3)
    {
        couple::set(e1, e2);
        m_third = e3;
    }
 
}; // class triplet
 
 
bool operator == (triplet const& lhs, triplet const& rhs)
{
    return ( (lhs.get_first() == rhs.get_first()) &&
             (lhs.get_second() == rhs.get_second()) &&
             (lhs.get_third() == rhs.get_third()) );
}
 
 
bool operator < (triplet const& lhs, triplet const& rhs)
{
    if (lhs.get_first() < rhs.get_first())
        return true;
 
    if (rhs.get_first() == lhs.get_first()) {
        if (lhs.get_second() < rhs.get_second())
            return true;
        return ( (lhs.get_second() == rhs.get_second()) && (lhs.get_third() < rhs.get_third()) );
    }
 
    return false;
}

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
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
class triplet
{
 
  public:
    typedef couple::first_type first_type;
    typedef couple::second_type second_type;
    typedef ... third_type;
 
  private:
    couple m_couple;
    third_type m_third;
 
  public:
    triplet() = default;
 
    triplet(first_type const& e1, second_type const& e2, third_type const& e3) : m_couple(e1, e2), m_third(e3)
    {}
 
    first_type const& get_first() const
    { return m_couple.get_first(); }
 
    second_type const& get_second() const
    { return m_couple.get_second(); }
 
    third_type const& get_third() const
    { return m_third; }
 
    void get(first_type& e1, second_type& e2, third_type& e3) const
    {
        m_couple.get(e1, e2);
        e3 = m_third;
    }
 
    void reset()
    {
        m_couple.reset();
        m_third = third_type();
    }
 
    void set(first_type const& e1, second_type const& e2, third_type const& e3)
    {
        m_couple.set(e1, e2);
        m_third = e3;
    }
 
}; // class triplet
 
 
bool operator == (triplet const& lhs, triplet const& rhs)
{
    return ( (lhs.get_first() == rhs.get_first()) &&
             (lhs.get_second() == rhs.get_second()) &&
             (lhs.get_third() == rhs.get_third()) );
}
 
 
bool operator < (triplet const& lhs, triplet const& rhs)
{
    if (lhs.get_first() < rhs.get_first())
        return true;
 
    if (rhs.get_first() == lhs.get_first()) {
        if (lhs.get_second() < rhs.get_second())
            return true;
        return ( (lhs.get_second() == rhs.get_second()) && (lhs.get_third() < rhs.get_third()) );
    }
 
    return false;
}

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
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
class triplet
{
 
  public:
    typedef ... first_type;
    typedef ... second_type;
    typedef ... third_type;
 
  private:
    first_type m_first;
    second_type m_second;
    third_type m_third;
 
  public:
    triplet() = default;
 
    triplet(first_type const& e1, second_type const& e2, third_type const& e3) : m_first(e1), m_second(e2), m_third(e3)
    {}
 
    first_type const& get_first() const
    { return m_first; }
 
    second_type const& get_second() const
    { return m_second; }
 
    third_type const& get_third() const
    { return m_third; }
 
    void get(first_type& e1, second_type& e2, third_type& e3) const
    {
        e1 = m_first;
        e2 = m_second;
        e3 = m_third;
    }
 
    void reset()
    {
        m_first = first_type();
        m_second = second_type();
        m_third = third_type();
    }
 
    void set(first_type const& e1, second_type const& e2, third_type const& e3)
    {
        m_first = e1;
        m_second = e2;
        m_third = e3;
    }
 
}; // class triplet
 
 
bool operator == (triplet const& lhs, triplet const& rhs)
{
    return ( (lhs.get_first() == rhs.get_first()) &&
             (lhs.get_second() == rhs.get_second()) &&
             (lhs.get_third() == rhs.get_third()) );
}
 
 
bool operator < (triplet const& lhs, triplet const& rhs)
{
    if (lhs.get_first() < rhs.get_first())
        return true;
 
    if (rhs.get_first() == lhs.get_first()) {
        if (lhs.get_second() < rhs.get_second())
            return true;
        return ( (lhs.get_second() == rhs.get_second()) && (lhs.get_third() < rhs.get_third()) );
    }
 
    return false;
}

Il me semble qu'il vaudrait mieux utiliser le troisième code, mais je me demandais s'il n'y avait pas une possibilité de réutiliser le code de la classe couple tout en restant cohérent/correct.

25/11/2011, 14h13
Klaim

Séparation oui a priori, mais il manque au triplet de quoi prendre des valeurs du couple, pour pouvoir travailler avec les deux, non?

Enfin je dis ça mais c'est peut être du feature creep.
25/11/2011, 14h32
Steph_ng8
Tu veux dire quelque chose comme ceci ?
Code:

1 2 triplet::triplet(couple const& c, third_type const& e3); void triplet::set(couple const& c, third_type const& e3);
Citation:

Envoyé par Klaim

Enfin je dis ça mais c'est peut être du feature creep.

Euh...
Pardon ? :? :aie:
25/11/2011, 15h16
koala01
Salut,

Pour moi, séparation, sans aucun doute...

On pourrait reporter cela aux points 2D par rapport aux points 3D...

Ce sont bel et bien des points, qui manipulent le meme type de valeur, mais il est hors de question de faire hériter un point 3D d'un point 2D, ne serait-ce que parce que leur utilisation sera tout à fait différente :aie:

Dans le meilleur des cas, tu peux envisager de fournir un opérateur de conversion triplet-> couple, mais...
1. quelle paire de ton triplet vas tu utiliser (1/2, 1/3, 2/3) :question:
2. Est ce que cela a un sens :question:
3. Est-ce qu'on peut se contenter de prendre une pair existante, ou faudra-t-il "transormer" les donnée :question:
Mais, je vais surtout dire ce qui me fait renoncer aux autres possibilités ;)
1. L'héritage public: on ne peut pas dire d'après LSP qu'un triplet est un couple, tout comme on ne peut pas dire qu'un carré est un rectangle (bien que ce soit mathématiquement le cas)
2. L'héritage privé : on ne peut pas estimer qu'un triplet soit implémenté en terme de couple... cela n'aurait aucun sens
3. La composition: cela nous obligerait à des indirections supplémentaires inutiles (avec nécessité de créer des fonctions "raccourcis" pour respecter demeter)
Non, décidément, rien ne vaut la séparation des pouvoirs :D
25/11/2011, 15h36
Steph_ng8
Citation:
Envoyé par koala01

Dans le meilleur des cas, tu peux envisager de fournir un opérateur de conversion triplet-> couple, mais...

quelle paire de ton triplet vas tu utiliser (1/2, 1/3, 2/3) :question:
Est ce que cela a un sens :question:
Est-ce qu'on peut se contenter de prendre une pair existante, ou faudra-t-il "transormer" les donnée :question:
1. Le type des éléments ne laisse pas le choix... ce n'est certes pas clair ici, mais ils sont tous différents (dans mon cas particulier en tout cas).
2. Tout à fait.
3. Une petite transformation sera nécessaire.
Pour plus de précisions, je te renvoie à l'exemple donné ici.
Citation:
Envoyé par koala01

Mais, je vais surtout dire ce qui me fait renoncer aux autres possibilités ;)

L'héritage public: on ne peut pas dire d'après LSP qu'un triplet est un couple, tout comme on ne peut pas dire qu'un carré est un rectangle (bien que ce soit mathématiquement le cas)
L'héritage privé : on ne peut pas estimer qu'un triplet soit implémenté en terme de couple... cela n'aurait aucun sens
La composition: cela nous obligerait à des indirections supplémentaires inutiles (avec nécessité de créer des fonctions "raccourcis" pour respecter demeter)
1. C'est bien pour cela que je ne l'ai pas proposé.
2. Je suis tout à fait d'accord. Disons que je me disais que l'on peut considérer que si l'on greffe une troisième donnée à un couple, ça devient un triplet... Le tout étant de savoir comment représenter correctement cette greffe... :roll:
3. Certes...
Quoi qu'il en soit, merci à vous de confirmer ce que je pensais. :mrgreen: ;)
25/11/2011, 15h54
koala01

Je n'attendais pas vraiment de réponse à mes remarques concernant l'opérateur de conversion, c'était essentiellement pour attirer l'attention sur ce qui peut te faire décider de ne pas en créer :D

Quand à l'héritage public, je ne l'ai mis que pour etre complet quant aux possibilités qui nous étaient données :D

Oh tiens, pendant que j'y pense, à propos de using :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 class triplet : private couple { (...) public: using couple::get_first; //******************// first_type const& get_first() const { return couple::get_first(); } };
Fondamentalement, quelles sont les différences entre les deux écritures ?
Point de vue compilateur/éditeur de lien, j'entends.
L'une d'elle est-elle plus rapide ? plus efficace ? plus gourmande en ressources ?
Si la fonction redéfinie est inlinée ? ne l'est pas ?

25/11/2011, 16h09
Steph_ng8

Citation:

Envoyé par koala01

Je n'attendais pas vraiment de réponse à mes remarques concernant l'opérateur de conversion, c'était essentiellement pour attirer l'attention sur ce qui peut te faire décider de ne pas en créer :D

Ouais, mais j'avais envie de répondre... :P
Et finalement, ça m'a plutôt donné envie d'en créer un... :mouarf:

Citation:
Envoyé par Steph_ng8
Oh tiens, pendant que j'y pense, à propos de using :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 class triplet : private couple { (...) public: using couple::get_first; //******************// first_type const& get_first() const { return couple::get_first(); } };
Fondamentalement, quelles sont les différences entre les deux écritures ?
Point de vue compilateur/éditeur de lien, j'entends.
L'une d'elle est-elle plus rapide ? plus efficace ? plus gourmande en ressources ?
Si la fonction redéfinie est inlinée ? ne l'est pas ?
Il me *semble* (cela demande donc vérification et doit, en attendant, être pris avec toutes les précautions d'usage :D )que la visibilité n'est utilisée qu'au niveau du compilateur, pour assurer que seul les objets ad-hoc ont accès à une variable ou à une fonction, mais qu'il n'y a aucune différence (hormis le mangeling du symbole :D) au niveau de la mémoire...

J'aurais donc tendance à dire que les deux sont parfaitement équivalent en terme de rapidité : la directive using disant au compilateur "ce que je t'ai dit qu'il fallait protéger (en le mettant privé), ben, je veux que tu le considères comme public / protégé" la fonction inline étant équivalente à dire "en fait, je rajoute une fonction pour la facilité, mais tu dois en réalité appeler telle fonction" :?

La seule certitude étant que tu perdra le temps de l'appel de la fonction si tu ne la rend pas inline ;)

26/11/2011, 19h16
3DArchi
Salut,
Même l'héritage privé de couple par triplet me dérange. J'aurais probablement plus vu une base commune à couple et à triplet contenant le code factorisé :
Code:

1 2 3 struct tuple_impl; struct couple : private tuple_impl; struct triplet : private tuple_impl;
26/11/2011, 19h23
koala01
Citation:
Envoyé par 3DArchi

Salut,
Même l'héritage privé de couple par triplet me dérange. J'aurais probablement plus vu une base commune à couple et à triplet contenant le code factorisé :

Code:

1 2 3 struct tuple_impl; struct couple : private tuple_impl; struct triplet : private tuple_impl;
Et même ainsi, je t'avouerai que je ne suis pas sur du tout d'y voir un quelconque intérêt :aie:

Comme je l'ai dit dans ma première intervention :

Citation:

L'héritage privé : on ne peut pas estimer qu'un triplet soit implémenté en terme de couple... cela n'aurait aucun sens

Même si c'est en terme de tuple_impl en l'occurrence :D
26/11/2011, 23h15
Steph_ng8

Citation:

Envoyé par 3DArchi

J'aurais probablement plus vu une base commune à couple et à triplet contenant le code factorisé :

Ah ouais, pas con... :ccool:

Citation:

Envoyé par koala01

Et même ainsi, je t'avouerai que je ne suis pas sur du tout d'y voir un quelconque intérêt :aie:

Réflexion faite... :|

Bien.
Merci de vos interventions, toujours aussi enrichissantes. :)