Discussion :

[Plomeg]

Bonjour,

Je voudrais avoir un avis sur des fonctions membres d'une classe.

Faut-il créer (et garder) des fonctions dont on ne se sert jamais à coup sûr dans les conditions du programme créé mais qui pourrait éventuellement (mais peu probable) servir un jour, dans une amélioration du programme en question? Je veux dire qu'on peut facilement écrire ou réécrire une fonction auparavant inutile pour des besoins nouveaux (le principe de l'objet il me semble) mais est-ce une bonne chose pour le programme au final ou est-ce également une mauvaise habitude pour des programmes plus gros et compliqués (pour l'instant je suis plutôt mauvais^^)?

Dans le même ordre d'idée, vaut-il mieux ajouter des données en apparence inutiles dans une classe ou vaut-il mieux les enlever?

Merci d'avance pour vos réponses.

[Spout]

Ta question n'est pas propre qu'au C++, et je te conseille de la poser dans la rubrique conception.

De mon avis, ça dépend fortement de ta politique de gestion des sources, des exigences de ta boîte si c'est pour le milieu professionnel,... Je ne pense pas qu'il y ait de bonne ou mauvaise réponse à ta question

[koala01]

Salut,

Tant que ton programme n'a pas été distributé, tu fais strictement ce que tu veux, mais, l'idéal reste quand même de fournir les fonctions qui sont nécessaires, et de ne pas surcharger avec des fonctions inutiles...

Par contre, une fois qu'un programme a été distribué (et c'est encore plus vrai avec les bibliothèques), toute fonction utilisée dans une version antérieure distribuée devrait rester présente dans la nouvelle version, même si elle est devenue "inutile"

[Mat007]

Salut,

A mon avis il faut retirer tout ce qui est inutile dans la mesure du possible, et c'est en general toujours possible bien qu'en effet moins facile dans le cas d'une diffusion (a un client, au public, etc..).
C'est encore mieux de ne pas ajouter quelque chose qui ne sert a rien (YAGNI).

MAT.

[koala01]

Mais il est vrai qu'au fur et à mesure de l'évolution, on peut se rendre compte que certaines méthodes deviennent obsolètes...

Dans le cadre d'une application complète, on peut envisager de les supprimer, mais, dans le cadre d'une bibliothèque, c'est une question de compatibilité que de les laisser, si, du moins, elle a déjà été diffusée...

[DavidDeharbe]

Je conseillerais de t'en tenir au strict nécessaire, et de consacrer tes ressources à vérifier que ce que tu développes est correct, efficace et bien écrit.

David.
--

[zais_ethael]

Heu,... c'est bien joli de donner des avis comme ça, mais faudrait recadrer un peu de quoi on parle vous ne pensez pas?
J'ai beau lire tout le thread, je ne vois toujours pas si on parle à l'échelle d'une classe ou d'un programme.
Je m'explique:
- à l'échelle de la classe: méthode proposant une fonctionnalité déja disponible dans une autre méthode ou par combinaison de plusieurs méthodes (exemple: la méthode at() et l'opérateur [] de std::vector sont redondants, il est toujours possible d'utiliser les itérateurs)
- à l'échelle du programme: méthode qui est indispensable pour pouvoir utiliser la classe de manière exhaustive mais qui, dans un programme donné, n'est pas utilisée (exemple: fstream qui fournit la possibilité d'ouvrir un fichier en lecture, on pourrait très bien concevoir un programme qui n'utilise que des fichiers en écriture, ou pas du tout évidemment)
Oui, je me rends bien compte que pratiquement tout le monde avait compris la première possibilité Mais je suis plus enclin à penser que Plomeg parlait de la deuxième...

[koala01]

Heu,... c'est bien joli de donner des avis comme ça, mais faudrait recadrer un peu de quoi on parle vous ne pensez pas?
J'ai beau lire tout le thread, je ne vois toujours pas si on parle à l'échelle d'une classe ou d'un programme.
Je m'explique:
- à l'échelle de la classe: méthode proposant une fonctionnalité déja disponible dans une autre méthode ou par combinaison de plusieurs méthodes (exemple: la méthode at() et l'opérateur [] de std::vector sont redondants, il est toujours possible d'utiliser les itérateurs)
- à l'échelle du programme: méthode qui est indispensable pour pouvoir utiliser la classe de manière exhaustive mais qui, dans un programme donné, n'est pas utilisée (exemple: fstream qui fournit la possibilité d'ouvrir un fichier en lecture, on pourrait très bien concevoir un programme qui n'utilise que des fichiers en écriture, ou pas du tout évidemment)
Oui, je me rends bien compte que pratiquement tout le monde avait compris la première possibilité Mais je suis plus enclin à penser que Plomeg parlait de la deuxième...

Pas forcément...

Ce qu'il importe de voir c'est si on a affaire

• à une application complete
• à une bibliothèque, et dans ce cas si
  
  • on la souhaite exhautive (optique suivie par la S(T)L)
  • on la souhaite minimaliste (en gardant l'optique de la compatibilité en tête)

Dans le premier cas, qu'il s'agisse d'une méthode de classe ou d'une "possibilité de l'application", si c'est inutile, il n'y a aucun problème à estimer que cela n'a pas sa place, en dehors de tout problème de compatibilité des arguments fournis aux applications qui peuvent être appelées en ligne de commande avec les versions antérieures déjà diffusées.

Dans le cadre d'une bibliothèque, et tant qu'elle n'a pas été diffusée, si tu ne la développe que pour l'utiliser dans une application bien précise et que ton optique reste minimaliste ( "du moment qu'elle me fournit toutes les possibilités qui seront nécessaires à la gestion de mon application" ), le principe reste le même

Par contre, si tu part sur l'idée d'une bibliothèque qui fournit les méthodes de gestion de manière exhaustive, parce que tu ne sais typiquement pas dans quelles circonstances elle sera utilisée, alors, là, il n'est pas du tout impossible que ce que tu estimes inutile (pour l'application que tu crées) puisse présenter un avantage majeur pour quelqu'un d'autre...

Au passage, la méthode at() et l'opérateur [] des vector ont un comportement malgré tout différent: at() lance une exception de type out_of_range si l'index fournit est supérieur au nombre d'éléments (exhaustivité, quand tu nous tiens )

[Mat007]

Par contre, si tu part sur l'idée d'une bibliothèque qui fournit les méthodes de gestion de manière exhaustive, parce que tu ne sais typiquement pas dans quelles circonstances elle sera utilisée, alors, là, il n'est pas du tout impossible que ce que tu estimes inutile (pour l'application que tu crées) puisse présenter un avantage majeur pour quelqu'un d'autre...

Si tu fais une bibliotheque sans savoir comment elle s'utilise c'est que quelque part il y a un probleme...

Je ne demords pas de mon avis, surtout que je n'ai jamais eu de probleme a l'appliquer : ne surtout pas ajouter quoique ce soit avant d'en avoir besoin (directement ou indirectement par retour utilisateur) et ne pas hesiter a virer quelque chose d'obsolete (tant qu'on explique aux utilisateurs pourquoi et par quoi c'est remplace).

MAT.
(desole pas d'accents sur mon systeme/clavier actuel)

[zais_ethael]

Au passage, la méthode at() et l'opérateur [] des vector ont un comportement malgré tout différent: at() lance une exception de type out_of_range si l'index fournit est supérieur au nombre d'éléments (exhaustivité, quand tu nous tiens )

Comme si je ne le savais pas , et qu'est-ce qui t'empèche de tester avec size()? Mais passons.

Je dirais que ton point de vue est celui du programmeur C++: je code ce dont j'ai besoin dans l'immédia.
Et le mien est celui du programmeur Java: plus c'est réutilisable et adaptatif mieux c'est, je n'ai même pas à me poser la question de savoir si cela pourrait être utile.
PS: ce n'est pas parcequ'un code est plus grand qu'il est plus compliqué, si vous savez l'organiser et le documenter correctement ça ne devrait jamais être le cas.

[Plomeg]

Merci pour vos réponses.

[koala01]

Si tu fais une bibliotheque sans savoir comment elle s'utilise c'est que quelque part il y a un probleme...

Je me suis peut être mal exprimé...

Ce que je voulais mettre en avant, c'est qu'il arrive que, quand tu crées une bibliothèque, tu remarque qu'il est possible (nécessaire ) d'appeler des fonctions de différentes manières, simplement, parce que plusieurs points de vue peuvent être utilisés...

Dés lors, comme tu ne peux que difficilement prévoir quel point de vue sera pris par l'utilisateur de la bibliothèque, ou bien, tu la fait "minimaliste", en ne fournissant que la gestion "d'un point de vue", ou bien tu la fait "exhaustive", et tu fournis dés lors l'ensemble des possibilités envisagées (ou tu trouve un "juste milieu" entre les deux )

Je ne demords pas de mon avis, surtout que je n'ai jamais eu de probleme a l'appliquer : ne surtout pas ajouter quoique ce soit avant d'en avoir besoin (directement ou indirectement par retour utilisateur) et ne pas hesiter a virer quelque chose d'obsolete (tant qu'on explique aux utilisateurs pourquoi et par quoi c'est remplace).

MAT.
(desole pas d'accents sur mon systeme/clavier actuel)

Je crois qu'il y a un problème de mauvaise compréhension quelque part, car on semble se "chamailler", alors que l'on dit en gros la même chose...

Je suis partisan de partir des principes "KISS", "YGANI" et autres qui incitent les gens à n'implémenter que ce dont ils ont vraiment besoin, mais, ce ne peut être valable, selon moi, que tant que l'application ou la bibliothèque ne s'est retrouvée que dans les mains du concepteur (ou de l'équipe de conception)...

En effet, il n'y a, à mon sens, que les grosses sociétés multinationales monopolistiques qui puissent se permettre d'estimer qu'il n'est pas grave que ce qui pouvait se faire avec la version 1 d'une application ne puisse plus se faire avec la version 2, ou qu'un code fonctionnant avec la version 1 d'une bibliothèque puisse ne plus fonctionner avec la version 2...

Je conçois très fortement le fait que l'on puisse décourager fortement l'utilisation d'une fonction devenue "obsolète", mais, à mon sens, il reste nécessaire de ne pas laisser cette fonction "s'évaporer dans la nature", et risquer le fait que, lors du passage de la version 1 à la version 2, le code créé il y a un an avec la version 1 ne vienne se plaindre qu'il ne trouve pas une fonction.

[JolyLoic]

Il peut être préférable d'amputer le code clairement d'une fonction non maintenue, plutôt que de la laisser gangrèner. Le mieux étant certes de la maintenir, mais à quel coût...

[Mat007]

Je conçois très fortement le fait que l'on puisse décourager fortement l'utilisation d'une fonction devenue "obsolète", mais, à mon sens, il reste nécessaire de ne pas laisser cette fonction "s'évaporer dans la nature", et risquer le fait que, lors du passage de la version 1 à la version 2, le code créé il y a un an avec la version 1 ne vienne se plaindre qu'il ne trouve pas une fonction.

Je me souviens d'une bibliotheque dans laquelle un nom d'une methode (publique) avait une faute de frappe et quand les auteurs s'en sont apercu ils ont decide de rajouter une methode avec le nom correct mais aussi de conserver l'ancienne justement pour que les utilisateurs puissent continuer a compiler leur 'vieux' code... C'est quand meme pousser un peu...

On ne peut rien faire 'tout bon' du premier coup, d'ailleurs on ne peut sans doute qu'y tendre en suivant un long processus de remaniement et d'affinage. Laisser s'accumuler du vieux code n'aide pas pour se rapprocher du 'tout bon'.

Mais oui bien sur on peut organiser la depreciation et integrer ca un peu intelligemment dans la gestion des versions et des livraisons.
Plus il y a d'utilisateurs et plus c'est important.

MAT.