Version imprimable
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.
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é.Citation:
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.
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.Citation:
Envoyé par Graffito
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.Citation:
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.
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.
8O Tu plaisantes ...Citation:
En .Net, cette mécanique est remplacée par les exceptions.
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 .
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.Citation:
Envoyé par bobosh
Je n'ai jamais dis le contraire. ReDire qu'utiliser les exceptions n'est pas performant revient à enfoncer une porte ouverte...Citation:
D'autant plus que la gestion des exceptions est extrémementt pénalisante pour les performances.
Sur quels arguments bases tu cette affirmations ?Citation:
D'une manière générale, les exceptions doivent être évitées dans toute la mesure du possible.
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.
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.
Tout à fait. Du même point de vue, je me vois mal utiliser uniquement l'un ou l'autre. L'essentiel étant de gérer convenablement les "erreurs". C'est quelquechose de pas si évident que ça au final, et j'ai pas vu beaucoup de programme le faire convenablement et simplement.Citation:
Envoyé par MetalGeek
Mais tout ceci est en dehors du post...
Si je comprends bien en lisant vos réponse, tout dépend des habitudes du développer ?
J'ai toujours eu l'habitude de retourner directement l'attribue que j'ai modifier pour éviter de resaisir une ligne de code par la suite mais je me suis posé cette question après une discussion avec un ami qui n'était pas d'accord sur ce principe. Il me disait, c'est sois on modifie la valeur, sois on la retourne mais pas les deux.
Je suis assez d'accord avec ce principe. Après tout, c'est comme ça que fontionnent les accesseurs des propriétés ("get" / "set"). Derrière le compilo pond des méthodes get_MaPropriété(valeur) et set_maPropriété(), et le nom de ces méthodes ne porte pas à confusion.Citation:
c'est sois on modifie la valeur, sois on la retourne mais pas les deux.
Après il y a aussi l'approche développeur couche d'accès à la BD : là on va retourner le nombre de lignes affectées par une modif/une suppression, etc. Mais c'est clairement pour éviter un second accès inutile à la base.
Oui, Pour les propriétés, il y a une génération de méthodes pour se rapporcher de l'objet. La présence d'un accesseur est une façon de présenter les attributs d'un objet en violation avec le principe d'encapsulation, pire encore pour le mutateur.Citation:
Envoyé par MetalGeek
Normalement l'objet veut que l'on utilise des méthodes pour en modifier les atributs. A priori les méthode de modification sont sencées retourner void... D'autres méthodes "type get" retournent une valeur sans modifier l'objet (comme ToUpper()). Ensuite C# n'est pas objet mais orienté objet, donc on se permet quelques libertées (comme dans tous les langages POO).
Au final, malgré les règles de bonne pratique, ce sont toujours les règles d'entreprise qui doivent primer (fussent-elles mauvaises) afin de donner une cohérence à l'ensemble du (et des) projet(s).
Enfin, pour rebondir sur les exceptions, un bon codage défensif empêche qu'il y en aie... Plus facile à dire qu'à faire ;)