Discussion :

[Davidbrcz]

Bonjour à tous !

Suite à la lecture de cette entrée de FAQ, j'ai appliqué le cas au pattern NVI en séparant dans une branche les différentes implémentations possibles, et dans une autre, les jeux de pré/post conditions.

Ca donne quelque chose comme ca :

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
 
#include<iostream>
 
struct A
{
  void foo()
  {
    pre();
    do_foo();
    post();
  }
protected: 
  virtual void pre()=0;
  virtual void post()=0;
 
  virtual void do_foo()=0;
};
 
struct B1 : virtual A
{
  void pre(){std::cout<<"Pre1"<<std::endl;}
  void post(){std::cout<<"post1"<<std::endl;}
};
 
 
struct B11 : virtual A
{
  void pre(){std::cout<<"Pre2"<<std::endl;}
  void post(){std::cout<<"post2"<<std::endl;}
};
 
struct B2 : virtual A
{
   void do_foo()
  {
    std::cout<<"B2::do_foo"<<std::endl;
  }
};
 
 
struct B22 : virtual A
{
   void do_foo()
  {
    std::cout<<"B22::do_foo"<<std::endl;
  }
};
 
struct C1 : B1, private B2
{};
 
struct C2 : B11, private B22
{};
 
void fun(A& a)
{
  a.foo();
}
 
int main()
{
  C1 c1;
  C2 c2;
  fun(c1);
  fun(c2);
}

De cette façon, on peut mixer modifier en jouant sur l'héritage le comportement de la classe , alors on les manipule toutes à travers la même interface.

Au final, ca ressemble assez aux classes de politique mais c'est entièrement dynamique.

Bref : qu'en pensez vous ? C'est une idée débile ? Ca peut servir dans une application ?

[oodini]

Je pense que la réflexion est la même que celle qui préside entre le choix d'un polymorphisme statique (CRTP) et dynamique (fonctions virtuelles).

[white_tentacle]

Ça me fait penser à de la programmation orientée aspect, mais en plus limité (un seul aspect à la fois). Et donc, oui, ça ressemble aussi à des politiques, du coup.

Mais la différence par rapport à avoir un pointeur vers une instance d’une classe de politique, si tu as besoin de politiques dynamiques… Je suis dubitatif . Mais c’est aussi parce que j’ai tendance à préférer le statique partout où c’est possible.

[JolyLoic]

Dans l'absolu, je n'ai rien contre le code, sauf que tu as nommé certaines fonctions pre/post. Or pour moi, tout l'intérêt de NVI est que les pré/post conditions ne sont pas un point de variation de ta classe. Donc à moins que j'ai loupé un truc, je ne vois pas trop où tu veux en venir.

[Davidbrcz]

Ça me fait penser à de la programmation orientée aspect, mais en plus limité (un seul aspect à la fois). Et donc, oui, ça ressemble aussi à des politiques, du coup.

J'ai jamais réussi à avoir quelque chose de vraiment fonctionnel en programmation par Aspect. Faudrait que je reteste un de ces 4.

Dans l'absolu, je n'ai rien contre le code, sauf que tu as nommé certaines fonctions pre/post. Or pour moi, tout l'intérêt de NVI est que les pré/post conditions ne sont pas un point de variation de ta classe. Donc à moins que j'ai loupé un truc, je ne vois pas trop où tu veux en venir.

Quand je l'ai écrit, j'avais en tête que les classes C1 et C2 offrent des services qui ait plus ou moins de chance de réussir selon le degré de sévérité des pré/post conditions. Mais c'est pas plus réfléchi que ca. Ca pourrait aussi pour intégrer du logging si tu as envie