Discussion :

[Jimalexp]

Salut,

Voici quelques questions qui me travaillent au niveau des fonctions :

1) Y aurais t-il un inconvénient à utiliser un return après un contrôle d'entrée au début d'une fonction ?

Code :

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

1
2
3
4
5
6
7
8
fonction booleen estMalade( Personne p )
{
si( p == null )
retourner faux;

(tests pour voir si malade)

}

Au lieu de :

Code :

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

1
2
3
4
5
6
7
8
9
10
fonction booleen estMalade( Personne p )
{
si( p != null )
{
(tests pour voir si malade)
}

retourner faux;

}

2) Dans le cas où l'on a beaucoup de fonctions qui portent sur une Personne, vaut-il mieux tester Personne à l'entrée ou tester Personne dans chaque fonction pour tenir compte des imprévus ?

[Garulfo]

Salut,

Voici quelques questions qui me travaillent au niveau des fonctions :

1) Y aurais t-il un inconvénient à utiliser un return après un contrôle d'entrée au début d'une fonction ?

2) Dans le cas où l'on a beaucoup de fonctions qui portent sur une Personne, vaut-il mieux tester Personne à l'entrée ou tester Personne dans chaque fonction pour tenir compte des imprévus ?

Dans le premier cas, tu brises a priori le paradigme de la programmation structuré. Ça « pourrait » rendre le programme moins lisible, moins compréhensible, augmenter les risques d'erreurs de logique etc. Maintenant, soyons honnête, si tu t'en tiens à ce genre de bris, tu n'as pas d'inquiétude à te faire. Quand tu fais, comme ici, une gestion d'erreur, il n'y a rien en plus qui contrevienne à utiliser un return en début de fonction, bien au contraire. En effet, normalement, si tu as un cas d'erreur, tu veux normalement « jeter » le reste du traitement puisque ce traitement n'est plus approprié. Pour être plus « technique » c'est un viol de précondition qui mène à un rejet du traitement. En écrivant dans ta deuxième forme, tu ajoutes donc en fait de la lisibilité au lieu d'en enlever par un code un peu plus concis et pas plus difficile à suivre.

Pour ta deuxième question, cela dépend du contexte et de tes besoins. Ceci va affecter ton architecture bien sûr. Toute fonction possède un ensemble de prérequis pour que le traitement soit valide: c'est ce qu'on appelle les préconditions. Ainsi tu peux dire que ta fonction f(x) est valide si on a que la précondition x>0 est vraie. Tu dois alors toujours t'assurer que les préconditions sont satisfaites. Mais si c'est le cas, tu t'épargnes tous les traitements qui pourraient résulter de cas particuliers. Cependant, tu peux vouloir diminuer la précondition, ce qui correspond un ajout de robustesse. Il te faut toi-même, dans ta fonction, tenir compte des cas problématiques.
- Pourquoi tenir compte de ces cas ? Parce qu'ainsi ta fonction est à même de traiter plus de cas et donc à moins de risque d'être un problème pour les utilisateurs de cette fonction.
- Pourquoi ne pas le faire alors ? Parce qu'une d'une part tu ne peux pas tout valider et que dans un projet d'envergure tu te dois d'admettre certaines préconditions qui ne seront validés qu'à des couches hautes (vers l'utilisateur) du système. Ça a pour effet aussi d'alléger ta fonction d'un point de vue du nombre de traitement, et donc du point de vue de la taille de ton code et de sa lisibilité. Or plus de lisibilité amène moins de risque d'erreurs (de bugs) dû à la confusion. Finalement ça peut largement améliorer tes performances. Supposes que ta fonction soit appelée dans une boucle 1 millions de fois. Si ces données ont déjà été validées une fois pour un traitement, veux-tu vraiment perdre du temps à les revalider. Il est toujours facile d'encapsuler ta fonction par une autre fonction qui va effectuer la validation, alors qu'il sera plus difficile, voir impossible, pour un futur programmeur d'extraire la partie sans validation.

Bon j'arrête là -_- Je vais pas te faire un cours non plus. Mais tu vois l'idée: tout dépend du contexte

[Jimalexp]

En effet, normalement, si tu as un cas d'erreur, tu veux normalement « jeter » le reste du traitement puisque ce traitement n'est plus approprié. Pour être plus « technique » c'est un viol de précondition qui mène à un rejet du traitement. En écrivant dans ta deuxième forme, tu ajoutes donc en fait de la lisibilité au lieu d'en enlever par un code un peu plus concis et pas plus difficile à suivre.

Donc ca ne choquerais personne de procéder ainsi à part cette perte de lisibilité. Il n'y aurais pas non plus de différence au niveau "fiabilité" dans des conditions normales.

Il reste une différence que j'ai remarqué hier. Lorsqu'on place les contrôles à l'entrée d'une fonction, on peut se retrouver avec une série de OU :

Code :

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

1
2
3
if( p == null || p.getEtat() == "sain" )
return;
(faire quelque chose)

Alors que cela serais restranscrit sous l'autre forme avec des ET (donc nécessité d'évaluer complètement l'expréssion ?) :

Code :

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

1
2
3
4
if( p != null && p.getEtat() != "sain" )
{
(faire quelque chose)
}

A part ça, les "feignants" verrons un avantage dans la première forme de part le fait que ça évite d'indenter le code qui suis.

- Pourquoi tenir compte de ces cas ? Parce qu'ainsi ta fonction est à même de traiter plus de cas et donc à moins de risque d'être un problème pour les utilisateurs de cette fonction.
- Pourquoi ne pas le faire alors ? Parce qu'une d'une part tu ne peux pas tout valider et que dans un projet d'envergure tu te dois d'admettre certaines préconditions qui ne seront validés qu'à des couches hautes (vers l'utilisateur) du système.

Pour reformuler, on va dire qu'une fonction devrais tout contrôler dans le cas de figure où l'on veut que cette fonction soit réutilisable ou parcequ'on ne sais pas dans quelles conditions elle sera appellée.

De l'autre côté, on peut se retrouver dans un contexte où il est très improbable que certaines conditions puissent changer. Par exemple, on ne va pas s'amuser à tester si certains packages existent dans du Java s'ils font partie d'une installation standard.

Il y a aussi une question de performance lors des traitements critiques (appels à répétition, impératif d'exécution dans un espace de temps assez réduit).

Donc, ce qu'on peut faire par exemple avec des fonctions internes à une classe ou un programme c'est de placer les instructions qui vont chercher des nouvelles informations à l'extérieur d'une boucle, ou autre structure répétitive, si possible et d'éffectuer les contrôles à ce niveau là. Une fois passé l'entrée du chateau, on suppose que les informations à traiter sont correctes.