Faut-il réellement déclarer des méthodes private ?

Quand je code, je sépare au maximum mes fonctions afin d'avoir un code plus claire et plus réutilisable possible, en général j'ai au max 10 ou 15 instructions par fonctions.

Une conséquence est que pour certain algo, bah j'ai pas mal de fonction.
Imagine que toutes ces méthodes soient public, on se retrouverait avec des APi avec 20, 30 méthodes, dont les 3/4 au final n'ont au intérêt d'être utilisé en dehors.
Et puis, ok dans ton cas la méthode a une utilité, mais dans une majorité des cas, la méthode privé n'a une utilité QUE dans une utilisation bien précise.

De plus encore une fois, la façon ont on code son API peut faire qu'une fonction ne peut être utiliser qu'avec certaine valeur de paramètre. Imagine que la fonction utilise une variable de classe. En privé, aucun problème c'est toi qui gère ca, tu sais quand la fonction est appelée quelle valeur doit avoir ces paramètres. Si jamais la fonction est publique, bah ce n'est plus le cas.

Je comprends bien ces derniers arguments, mais cela implique que le développeur de la classe doit présupposer ce qui va être utile ou non à l'utilisateur.

Je trouve le risque est grand de se tromper et de mal estimer l'utilisation de la classe. C'est en tout cas ce qui se produit dans mon cas.

Citation:

---

Envoyé par fredmn

Le cas qui m'intéresse et qui a provoqué mon interrogation serait plutôt similaire à celui-ci :

- une méthode publique : redimensionnerImage(échelle)
- une méthode privée : redimensionnerImage(hauteur, largeur)

(avec bien évidemment la méthode redimmensionnerImage(échelle) qui appelle redimmensionnerImage(hauteur, largeur))

conséquence : je ne peut donc appeler redimensionnerImage(hauteur, largeur) alors que c'est exactement ce dont j'aurais besoin.

ps : j'ai bien conscience que mon interrrogation bouscule l'idéologie objet, mais je le redis, cela me chiffonne de retaper du code déja existant.
pps : merci en tout cas aux personnes qui prennent du temps pour discuter.

---

ca c'est le concept de Facade en gros
tu ne proposes au client que 2-3 methodes points d'entree de ton API le reste etant prive
si une methode privee te parait utile, c'est peut etre qu'il faut l'ajouter a l'API qui est incomplete dans ce ca la

Non, si l'API est faite comme les pieds, l'utilisateur n'a pas besoin des fonctions privés. S'il en a besoin, ce que l'utilisateur a fait de mauvais choix technique, sans en utilisant cette API qui ne répond pas à ses besoins, soit en ayant utilisé une mauvaise architecture.

Citation:

---

Je comprends bien ces derniers arguments, mais cela implique que le développeur de la classe doit présupposer ce qui va être utile ou non à l'utilisateur.

Je trouve le risque est grand de se tromper et de mal estimer l'utilisation de la classe. C'est en tout cas ce qui se produit dans mon cas.

---

Je pense que le risque inverse est bien plus problématique : un utilisateur qui présuppose mal de la manière d'utiliser d'une fonction prévue a usage interne uniquement :
- La fonction peut changer ou disparaitre.
- Il est possible qu'elle nécessite aussi des actions particulières pas forcément évidentes, pour fonctionner correctement
- Il peut aussi arriver que la fonction ne fonctionne pas dans des cas particulier dont l'auteur se fiche car il sait qu'ils ne peuvent arriver dans sa propre classe.

Surtout qu'il vaut mieux qu'une personne, celle qui a développé l'API se creuse la tête un peu, plutôt que les n personnes suivantes qui l'utilisont :mrgreen:.

Enfin bon monsieur cherchait plus le code pour faire la fft que d'utiliser l'API développé dans un but précis.

Citation:

---

Envoyé par Uther

Je pense que le risque inverse est bien plus problématique : un utilisateur qui présuppose mal l'utilisation d'une fonction prévue a usage interne dont le fonctionnement peut changer, ou nécessiter des actions particulières pas forcément évidentes pour fonctionner correctement, ...

---

je serais du meme avis

une API c'est fait pour evoluer, proposer de nouvelles fonctionnalites mais ne pas peter ton code dans la mesure du possible (plutot alterer le resultat attendu)

s'il n'y a plus que des methodes publics alors que certaines ne devraient etre qu 'a usage interne, tu vas etre susceptible de les utiliser, alors qu'elles a la prochaine version sont susceptibles d'avoir un comportement tout a fait different, et du coup de peter le fonctionnement de ton application ...

Outre les arguments qui ont été évoqués précédement, il existe différents points de vue quand au choix de la visibilité d'une méthode.

* Le choix de la visibilité d'une méthode peut se faire selon la nécessité de pouvoir la tester. En effet, il n'est pas possible d'écrire un test unitaire pour une méthode private. Donc une méthode complexe ou sensible devra être public pour pouvoir la tester.

* Le choix peut aussi se faire selon l'utilisation que l'on veut permettre de son api. Pour être concret, une approche orientée interface est l'écriture d'un bundle osgi dans lequel seules les méthodes exposées par le service sont accessibles. Il s'agit d'une approche radicalement orientée client.