Discussion :

[koala01]

Cela ne suffit peut etre pas, mais, si doSomething réagit différemment en fonction de l'état dans lequel est l'objet tout en fournissant un résultat final similaire, c'est que les deux états peuvent être considérés comme cohérents.

Le problème avec init, c'est que, a priori, l'objet est dans un état incohérent avant d'avoir été initialisé : une personne qui n'aurait pas de nom, ou un objet qui ne dispose pas des "caractéristiques minimales" qui permettent de le considérer comme tel.

Or, a priori, ce n'est pas à l'utilisateur de veiller à ce que l'objet reçu soit dans un état cohérent, mais bien à la classe, qui doit s'assurer que l'objet créé sera dans un état cohérent dés le moment où l'objet est créé

[r0d]

Ok alors, concrètement, qu'est-ce qu'un état cohérent?

C'est ce que j'essaie de montrer: ce n'est pas aussi simple de déterminer ces notions de "utilisable", "cohérent", etc.

Par exemple, il ne me semble pas absurde d'imaginer qu'une instance de classe puisse être utile même si tous ces champs (variables membres) ne sont pas remplis. Si récupère le champ nom (via l'accesseur getName) et que c'est une chaine vide, ce n'est pas forcément un problème et on peut peut-être continuer nos traitements, dans le cas où l'information n'est pas indispensable. Si maintenant getName() accède a des ressources externes susceptibles de lever une exception, on peut, de la même manière, imaginer récupérer cette exception et continuer nos traitements.

Avant de continuer, y a-t-il une hérésie dans la situation que je décris dans ce paragraphe?

[Flob90]

@r0d: Je ne vois pas en quoi ma définition est insuffisante.

Si ta fonction fait des choses différentes selon l'état, alors c'est qu'elle ne travaille pas seulement selon des invariants, rien de plus.

Je ne suis pas chercheur en informatique théorique (même pas chercheur tout court), mais je suis convaincu que tu dois avoir des gens qui ont déjà définies tout ça de manière très rigoureuse (sans trop réfléchir, je dirais théorie des graphes et théorie des ensembles).

Pour ton dernier message, un champs vide peut-être un état valide, c'est à toi, développeur, de choisir l'ensemble de tes états valides. Pas exemple, les pointeurs intelligents et les conteneurs, ont un état valide où ils ne référencent/contiennent rien.

Par contre se retrouver avec un objet dont l'état n'est valide que pour une fonction (init) et ne sera valide qu'après un appel à cette fonction pour les autres fonctions, ca doit inciter à se demander si il n'y a pas une mauvaise répartition invariant/pré-conditions. Typiquement, est-ce que l'introduction d'un type supplémentaire ne permettrait pas de résoudre le problème ?

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
 
//Avec init
struct A
{
  //Invariant A
  void init(/*needed params C*/)
  { /*Post-Condition B*/ }
 
  void foo()
  { /*Pre-Condition B*/ }
}
 
//Avec intérmédiaire
struct BeforeA
{
  //Invariant A
}
 
struct A
{
  //Invariant A+B
  A(BeforeA, /*needed params C*/)
  { }
 
  void foo()
  { }
}

Après l'idéal serait que BeforeA ai une réalité sémantique, ça reste envisageable selon la situation selon moi.