Discussion :

[bobosh]

Bonjour tout le monde,

Je code une application en c# et
je me posais une question bête par souci du respect des conventions de codage :

Quand je crée une classe, je vais créer divers méthodes, certaines de celle ci vont modifier l'objet et je me demandais si ces méthodes qui modifie l'objet par respect des conventions ne devait rien retourner en règle général.

Merci bien.

[Graffito]

je me demandais si ces méthodes qui modifie l'objet par respect des conventions ne devait rien retourner en règle général.

De nombreuses méthodes renvoient un code retour indiquant le succès ou l'echec de la fonction, ce qui montre qu'adopter une convention "void" pour les méthodes qui modifient l'objet est injustifié.

[cybermaxs]

De nombreuses méthodes renvoient un code retour indiquant le succès ou l'echec de la fonction, ce qui montre qu'adopter une convention "void" pour les méthodes qui modifient l'objet est injustifié.

La méthode qui consistent à retourner des codes retour n'est plus adaptée à DotNet ! On faisant ça en C et autres langages plus anciens de programmation fonctionnelle car c'était la méthode la plus pratique. En .Net, cette mécanique est remplacée par les exceptions.

certaines de celle ci vont modifier l'objet et je me demandais si ces méthodes qui modifie l'objet par respect des conventions ne devait rien retourner en règle général.

Tout dépend de ce que font tes méthodes. Par exemple, sur une méthode qui fait un enregistrement en base, il est pertinent d'avoir un retour. L'important est de te fixer des conventions qui seront respectées dans tout le code.

[bobosh]

Je suis tout à fait d'accord sur le principe de renvoyer quelque chose pour verifier le statut d'une fonction (echec ou reussite).

Mais prenons le cas simple d'une classe Personne.

Si elle possede un attribue age, et une methode anniversaire qui ajoute un à cet age, pour question de pratique et de rapidité on aurait pu renvoyer par l'intermediaire de la fonction cet attribue age.

Mais j'ai l'impression que ce n'est pas vraiment correcte.

[cybermaxs]

Mais prenons le cas simple d'une classe Personne.

Si elle possede un attribue age, et une methode anniversaire qui ajoute un à cet age, pour question de pratique et de rapidité on aurait pu renvoyer par l'intermediaire de la fonction cet attribue age.
Mais j'ai l'impression que ce n'est pas vraiment correcte.

Oui, mais faire retourner void n'est beaucoup plus performant. Ce n'est pas un critère significatif dans ce cas. A ce niveau c'est aussi de la finesse. Je préfère personnellement renvoyer la nouvelle donnée, histoire de gagner une ligne de code par la suite.

D'autant plus que la gestion des exceptions est extrémementt pénalisante pour les performances.

Je n'ai jamais dis le contraire. ReDire qu'utiliser les exceptions n'est pas performant revient à enfoncer une porte ouverte...

D'une manière générale, les exceptions doivent être évitées dans toute la mesure du possible.

Sur quels arguments bases tu cette affirmations ?
Les exceptions ont été introduites pour palier aux problèmes des codes de retour. Chaque méthode peut potentiellement renvoyer une liste de codes de retours. En plus de gérer chaque possibilité individuellement dans la méthode, c'est l'appelant qui va devoir gérer chaque éventualité en gros dans un if/switch, ce qui alourdi déjà pas mal le code. Chaque méthode peut en plus appeler d'autres méthodes qui elles aussi auront leurs propres codes en retour. Mais attention, tu ne peux pas "oublier" de traiter un code, car tout ton traitement dépendra peut être d'un objet pas initilisé correctement. Il n'y a pas de gestion globale possible non plus.
Les exceptions sont une avancée majeure dans le développement. Certes, ils doivent être utilisées avec parcimonie, mais c'est tout de même beaucoup plus puissant.

[MetalGeek]

Salut,

une "exception" porte bien son nom. En général on lève une nouvelle exception (c'est-à-dire on en instancie une, qu'elle soit personnalisée dérivée de Exception ou ApplicationException, ou une d'une classe existante) lorsque le code exécute quelque chose qui ne doit pas être faisable (ex. appel à une méthode qui requiert un argument, et dont le comportement avec cet argument à 'null' n'est pas pertinent => on lève une nouvelle "ArgumentNullException").
Pour des cas du genre mauvaise saisie utilisateur, on va plutôt parler de "validation" : par ex. si on demdande l'âge d'une personne, que l'utilisateur rentre ' - 212', on va tester la valeur et retourner un code d'erreur (ou valoriser une propriété du genre "IsValid" à false etc), enfin disons qu'on ne va pas lever d'exception, puisque ce cas de figure et prévu et géré par le programme.
Enfin tout ça pour dire que pour moi, les codes de retour et les exceptions peuvent tout à fait cohabiter dans la programmation .NET, les finalités n'étant pas les mêmes.

[Graffito]

En .Net, cette mécanique est remplacée par les exceptions.

Tu plaisantes ...
D'une manière générale, les exceptions doivent être évitées dans toute la mesure du possible.
D'autant plus que la gestion des exceptions est extrémementt pénalisante pour les performances .