Discussion :

[Luc Hermitte]

L'intérêt est la symétrie qui pourrait être la bienvenue le jour où il rajoute un constructeur de conversion, depuis un std::time_t p.ex.
Et effectivement, ce n'est pas le cas pour l'instant.

Maintenant, j'ai zappé le fait qu'il puisse y ajour un problème avec son implémentation actuelle de l'opérateur d'égalité.

[gl]

L'intérêt est la symétrie qui pourrait être la bienvenue le jour où il rajoute un constructeur de conversion, depuis un std::time_t p.ex.

Autant sur des opérateurs du style de +, -, etc. cet argument me parle et j'ai effectivement tendance à les implémenter en non-membre.

Autant sur des opérateurs de conversion, je préfère les implémenter en tant que membre mais c'est essentiellement parce que je n'apprécie que modérément de comparer deux objets de type différent. Maintenant, il est clair que je fais des exceptions.

[3DArchi]

Salut,

J'ai bien compris ce que tu voulais dire et faire de l'objet c'est respecter la notion de private avec les attributs.

Donc j'ai revu mon code en conséquence et donc par exemple mon code pour == est devenu :

Code :

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

1
2
3
4
5
6
7
8
bool operator == (const Date& d1,const Date& d2){
    if( (d1.mDay==d2.mDay)
	&& (d1.mMonth==d2.mMonth)
	&& (d1.mYear==d2.mYear) ) {
	return true;
    };
    return false;
}

Mais là, forcément, mDay mMonth mYear c'est public... Donc le compilateur crie au scandale.
Qu'est ce que je dois faire docteur?

Comme montré pour l'exemple de l'opérateur << dans mon message précédent, dans le cadre de cet opérateur défini à l'extérieur de la classe, l'utilisation de l'amitié (friend) est une solution qui ne rompt pas l'encapsulation.

Je trouve ta remarque pleine de bon sens. S'il y a des problèmes autant les régler à la source. J'ai donc essayé de coder un truc mais je suis vraiment pas satisfait. Mettre NULL ou delete impliquerait utiliser des pointeurs, or mes variables ne le sont pas. Ce sont des int et des bool

Tout ceci prouve que tu ne devrais pas gérer d'état invalide. Car à chaque fois se pose la question de comment représenter cet état et quelle sémantique lui donner. Ce qu'il y a dans IsValid ressemble peu ou prou aux invariants de ta classe. Le reste est la prédoncition de ton constructeur. Tu ne devrais pas donner trop de responsabilité à ta classe : à charge de celui qui l'utilise de l'utiliser correctement. S'il ne le fait pas, alors le contrat est rompu et qu'il ne s'étonne pas d'avoir des résultats aberrants. Fais-une recherche sur la programmation par contrat.

De plus, écrire

Code :

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

),mIsLeapYear(IsLeapYear())

c'est correct?

Tu appelles une méthode de ton objet avant que la construction de celui-ci ne soit terminée. Si IsLeapYear n'utilise que des membres à gauche de la liste d'initialisation, donc des membres déjà construits, alors il n'y a pas de problème. En revanche, s'il utilise des membres à droite, alors ces membres ne sont pas encore construits et le comportement est indéterminé. C'est à cause de ces raisons qui ne sont pas immédiates et peuvent apporter de la confusion en lecture de code, que j'évite autant se peut d'utiliser une fonction membre pour initialiser une variable membre. Qui sait comment sera comprise et modifiée la chose par les suivants.

[-={-_-}=-]

Tu n'en n'as pas besoin en dehors du constructeur. Et si les paramètres sont invalides => exception et on n'en parle plus.
Quand aux additions, additionner un nombre de jours ou de mois à une date (valide par construction) devrait toujours produire un résultat valide. Inutile de se trimballer l'état.

Je suis d'accord dans les additions, la date de sortie sera toujours valide mais je dois dans la fonction vérifie cet état de validité car 28/02/2009 +1 pourrait donner 29/02/2009 mais comme cette date n'est pas valide j'obtiens 01/03/2009.
Je ne suis pas d'accord qu'il est inutile de trimballer cet état mais par contre je pense qu'il faudrait mettre cette fonction en private. C'est ca que tu voulais dire?

Je trouve ta remarque pleine de bon sens. S'il y a des problèmes autant les régler à la source. J'ai donc essayé de coder un truc mais je suis vraiment pas satisfait. Mettre NULL ou delete impliquerait utiliser des pointeurs, or mes variables ne le sont pas. Ce sont des int et des bool

Tout ceci prouve que tu ne devrais pas gérer d'état invalide. Car à chaque fois se pose la question de comment représenter cet état et quelle sémantique lui donner. Ce qu'il y a dans IsValid ressemble peu ou prou aux invariants de ta classe. Le reste est la prédoncition de ton constructeur. Tu ne devrais pas donner trop de responsabilité à ta classe : à charge de celui qui l'utilise de l'utiliser correctement. S'il ne le fait pas, alors le contrat est rompu et qu'il ne s'étonne pas d'avoir des résultats aberrants. Fais-une recherche sur la programmation par contrat.

Je trouve ca bizarre ce que tu dis de laisser des résultats abérrants :-)
Ce que je voulais faire c'est dans le constructeur si la date n'est pas valide ben direct je le détruis.
Ok je vais regarder la programmation par contrat.


En tout cas je souhaitais tous vous remercier de participer à ma discussion, j'apprends vraiment trop de truc. merci a tous.

[Luc Hermitte]

Privée est une possibilité.

[3DArchi]

Je trouve ca bizarre ce que tu dis de laisser des résultats abérrants :-)

Une réponse rapide est de dire que c'est un peu le principe de la programmation par contrat : la classe établit un contrat avec son client. Si le client respecte le contrat (appels avec des paramètres valides entre autres), alors la classe donne un résultat attendu. Si le client ne respecte pas le contrat en fournissant des paramètres invalides par exemple, alors le comportement est indéterminé. Cela a comme avantages, entre autres, de simplifier le design des classes et de bien déterminer les responsabilités de chacun.

[-={-_-}=-]

Merci pour tout je pense que c'est OK.
Si au cas ou j'ai encore un pb, je le rouvrirais
Notamment si je veu faire evoluer ma classe vers une classe de durée.
Mais je pense avoir pas mal d'élements.
Merci à tous d'avoir participer