Bonjour,
J'ai une question concernant la rupture des invariants en C++. En g�n�ral, on dit que les invariants s'appliquent � l'ext�rieur d'une classe : Meyer himself
It describes a consistency property that every instance of the class must satisfy whenever it's observable from the outside
Donc un objet est construit de fa�on � respecter ses invariants, ensuite chaque fois qu'une fonction est appel�e en respect du contrat, les invariants sont toujours respect�s lorsque l'appelant r�cup�re l'objet.
En revanche, � l'int�rieur d'une fonction, l'invariant peut �tre momentan�ment rompu du moment qu'il est r�tabli avant la fin de la fonction.
Soit une classe C, dans une fonction F1, au moment o� un invariant est rompu, s�mantiquement :
-> (1) F1 a-t-elle le droit d'appeler une m�thode publique (non virtuelle) C::F2 sans r�tablir les invariants ? J'aurais tendance � dire que non, car cette m�thode �tant publique, le respect des invariants est une pr�condition implicite.
-> (2) F1 a-t-elle le droit d'appeler une m�thode priv�e (non virtuelle) C::F2 sans r�tablir les invariants ? J'aurais tendance � dire que oui, car cette m�thode �tant priv�e, seule C peut l'appeler et �ventuellement savoir qu'elle peut l'appeler sans respecter certains invariants. On est dans le cas o� non 'observable from the outside".
-> (3) F1 a-t-elle le droit d'appeler une m�thode prot�g�e (non virtuelle) C::F2 sans r�tablir les invariants ? Je ne sais pas trop quoi r�pondre car cette m�thode n'est pas accessible � l'ext�rieur mais elle l'est par les classes d�riv�es.
Rajoutons l'h�ritage et supposons que C d�rive de B :
-> (4) F1 peut-elle appeler une m�thode publique (non virtuelle) de la classe B sans r�tablir les invariants ? J'aurais envie d'avoir la m�me analyse que pour (1)
-> (5) F1 peut-elle appeler une m�thode prot�g�e (non virtuelle) de la classe B sans r�tablir les invariants ? Idem qu'en (3), je ne sais pas trop quoi en penser.
Maintenant, supposons une classe D d�rivant de C.
La r�solution dynamique de l'appel d'une fonction virtuelle ne tient pas compte de la visibilit� de la fonction virtuelle, ni dans la classe C, ni dans la classe d�riv�e D. D'o�
-> (6) F1 peut-elle appeler une m�thode virtuelle sans r�tablir les invariants ?
-> (7) Faut-il dissocier fonctions virtuelles pures ou non ?

En fait, les questions (3), (5) et (6) ( (7) devrait �tre une cons�quence de la r�ponse aux trois premi�res), � mon avis, trouvent leur r�ponse dans une question plus g�n�rale :
Est-ce qu'une classe de base B ou une classe d�riv�e D de la classe C est externe � C ?
Si la r�ponse est oui, alors F1 doit r�tablir les invariants dans les cas (3), (5) et (6) et il n'y a pas de diff�rence que les fonctions soit virtuelles pures ou juste virtuelles.
Si la r�ponse est non, alors quelles sont les conditions valides pour les diff�rents appels ?
Et, l� j'avoue que je ne sais pas trop quoi r�pondre. J'ai envie d'avoir une approche 'forte' (r�pondre 'oui') qui implique alors que :
-> (8) Pour un appel d'une fonction non virtuelle d'une classe de base, les invariants de la classe de base et de la classe C doivent �tre respect�s ;
-> (9) Pour un appel d'une fonction virtuelle (donc potentiellement d'une sp�cialisation de la classe d�riv�e), les invariants de la classe C doivent �tre respect�s.

On pourrait avoir une approche plus souple concernant (8) en disant que seuls les invariants de la classe de base doivent �tre respect�s. Mais si celle-ci fait appel � une m�thode virtuelle, elle peut �tre amen�e � appeler une fonction d'une classe d�riv�e sans respecter les invariants. Quid ?

Le pattern NVI a l'avantage de dissocier le contrat de la classe vis-�-vis de l'ext�rieur stricto-sensu d'un c�t� et de classes d�riv�es de l'autre. En ce sens, l'utilisation de ce pattern peut apporter des souplesses : le non-respect d'un invariant peut faire partie du contrat de la fonction virtuelle. En g�n�ralisant un peu, est-ce que la port�e de la fonction virtuelle si elle est ignor�e syntaxiquement ne devrait pas �tre prise en compte dans le contrat pour savoir quelle politique appliqu�e sur les invariants ? Difficile de r�pondre car une classe d�riv�e peut changer la port�e d'une fonction.
Je n'ai pas vraiment trouv� de r�ponses satisfaisantes � ces interrogations. J'aurais aim� conna�tre votre vision de cet aspect ?
Je ne sais pas si j'ai �t� suffisamment clair...