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

Bonjour a tous,

je me pose la question de la pertinence de la déclaration des méthodes en private. Je comprends bien les arguments d'encapsulation qui conduisent à ne déclarer public que les choses réellement importantes (effet boite noire). Mais franchement, il y a de nombreux cas ou le travail accompli dans une méthode private peut-être utile.

Je sais que dans ce cas, il est possible par héritage d'exploiter la méthode private. Mais si l'on considère les langages de scripts, de plus en plus populaires, qui permettent d'exploiter une librairie donnée, certains ne permettent pas l'héritage. On est réduit donc dans ce cas à faire un mix (inutile) de java-langage de script, simplement pour écrire une classe bidon.

Je pose donc la question : est-il réellement utile de déclarer des méthodes private, avec la tendance script de la jvm ?

Oui si on veut pas que cette méthode soit visible de l'extérieur, comme tu l'as bien compris.
Je pense tout de suite à l'exemple du pattern singleton qui déclare un constructeur privé, pour ne pas permettre la création d'instances.

ok, mais qu'est ce qui peut "réellement " justifier une telle invisibilité ?

Imaginons une librairie open-source, donc avec une volonté de partage du code. Est-ce cohérent de mettre des méthodes private dans cette librairie, ce qui va empécher leur utilisation éventuelle ?

Salut,

Citation:

---

Envoyé par fredmn

ok, mais qu'est ce qui peut "réellement " justifier une telle invisibilité ?

Imaginons une librairie open-source, donc avec une volonté de partage du code.

---

La visibilité des attributs/méthodes n'a rien à voir avec une éventuelle licence open-source ou autre...

La visibilité permet de cacher des attributs/méthodes qui serait directement inutile par les utilisateurs de la classe.


a++

PS : et une méthode private ne peut pas être utilisé via un héritage...

Citation:

---

Envoyé par fredmn

Bonjour a tous,

je me pose la question de la pertinence de la déclaration des méthodes en private. Je comprends bien les arguments d'encapsulation qui conduisent à ne déclarer public que les choses réellement importantes (effet boite noire). Mais franchement, il y a de nombreux cas ou le travail accompli dans une méthode private peut-être utile.

Je sais que dans ce cas, il est possible par héritage d'exploiter la méthode private. Mais si l'on considère les langages de scripts, de plus en plus populaires, qui permettent d'exploiter une librairie donnée, certains ne permettent pas l'héritage. On est réduit donc dans ce cas à faire un mix (inutile) de java-langage de script, simplement pour écrire une classe bidon.

Je pose donc la question : est-il réellement utile de déclarer des méthodes private, avec la tendance script de la jvm ?

---

dans ce cas la, est-il utile d'utilliser le protected ?
pourquoi ne pas mettre des public partout ?

ca c'est la reponse a cette question d'un prof que j'ai eu en fac :
les mots cles, c'est pour dans ta tete, public partout c'est pareil ...

1. C'est justement le point qui me chagrine : comment quelqu'un peut-il savoir que la méthode m'est inutile ? Il se trouve que je suis justement dans le cas où une méthode me serait utile, mais je ne peut y accéder.

2. Je trouve au contraire le lien avec l'open-source pertinent. Quel interet à publier une librairie en open-source, si c'est pour interdire l'utilisation de certaines méthodes. Je trouve cela contradictoire dans les intentions.

ps : si en plus, je n'y ai même pas accès en private, j'ai franchement du mal à comprendre.

Citation:

---

Envoyé par fredmn

1. C'est justement le point qui me chagrine : comment quelqu'un peut-il savoir que la méthode m'est inutile ? Il se trouve que je suis justement dans le cas où une méthode me serait utile, mais je ne peut y accéder.

---

Le mieux serait que tu décrives le problème que tu rencontres...

Citation:

---

Envoyé par fredmn

2. Je trouve au contraire le lien avec l'open-source pertinent. Quel interet à publier une librairie en open-source, si c'est pour interdire l'utilisation de certaines méthodes. Je trouve cela contradictoire dans les intentions.

---

Encore une fois cela n'a rien à voir avec l'open-source.
Si la méthode est private c'est que le développeur considère qu'il s'agit de traitement interne dont les utilisateurs de la classe ne devront pas utiliser directement...

Citation:

---

Envoyé par fredmn

ps : si en plus, je n'y ai même pas accès en private, j'ai franchement du mal à comprendre.

---

private = accès interdit

a++

Effectivement, comme je vois que l'on ne se comprend pas, je décris mon problème.

Je travaille avec ImageJ, une plateforme qui permet de faire du traitement d'image. ImageJ s'utilise avec un système de plugin qui effectue certains traitements. Les plugins sont codés sous forme de classes.
Mon objectif est de réaliser un plugin qui exploite une fft. Il se trouve qu'il existe un plugin fft, que je peux appeler mais qui est bouré d'effet de bord non-désiré (affichage d'images entre autres). Je désire donc calculer une fft mais je ne peut utiliser les méthodes publique du plugin qui me produise ces effets indésirables.

En fouillant dans le code du plugin, je constate qu'il existe des méthodes qui calculent la fft, mais comme elle sont déclarées private, je ne peut y accéder. La seule méthode publique est celle qui est pleine d'effet de bord.

Le cas de ton plugin est un parfait exemple de l'intérêt de l'encapsulation. Pour l'auteur du plugin, la seule méthode dont le fonctionnement doit être garantit pour l'extérieur est la méthode public. La méthode faisant la FFT est une méthode interne qui ne fait pas partie des services que le plugin fournis.
Supposons que l'auteur modifie son plugin pour qu'il arrive au même résultat sans avoir recourt a une FFT. Il peut supprimer cette méthode sans se demander si elle manquera à quelqu'un : c'est une méthode private.

private n'a pas de notion de libre accès au code source, il permet de délimiter les zone d'action de chaque objet. Si on ne fait pas attention a la conception a ce qui doit être accessible de l'extérieur ou non, on peut arriver a des cas ou tout dépend de tout, et dès que l'on touche quelque-chose, plus rien ne marche.

Il est possible via l'introspection de briser cette limitation, mais je ne le conseille pas. Si le code est libre, il te suffit de le reprendre dans ta propre méthode avec les accès que tu souhaites.

Citation:

---

Le cas de ton plugin est un parfait exemple de l'intérêt de l'encapsulation. Pour l'auteur du plugin, la seule méthode dont le fonctionnement doit être garantit pour l'extérieur est la méthode public. La méthode faisant la FFT est une méthode interne qui ne fait pas partie des services que le plugin fournis.
Supposons que l'auteur modifie son plugin pour qu'il arrive au même résultat sans avoir recourt a une FFT. Il peut supprimer cette méthode sans se demander si elle manquera à quelqu'un : c'est une méthode private.

---

Dans ce cas particulier, il ne pourra jamais supprimer la fft de son plugin, puisque le plugin calcule et affiche une fft. Ce qui me gène c'est que je ne peux pas calculer la fft, sans l'afficher.

Citation:

---

private n'a pas de notion de libre accès au code source, il permet de délimiter les zone d'action de chaque objet. Si on ne fait pas attention, on peut arriver a des cas ou tout dépend de tout, et dès que l'on touche quelquechose, tout s'arrête de marcher.

---

Bon. Je sens bien que je ne touche personne sur le parallèle entre code open-source et méthode private, donc je laisse tomber.

Citation:

---

Il est possible via l'introspection de briser cette limitation, mais je ne le conseille pas. Si le code est libre, il te suffit de le reprendre dans ta propre méthode avec les accès que tu souhaites.

---

Donc c'est bien l'objet de mon questionnement, impossible de réutiliser cette fonctionnalité sans recopier le code source et donc m'obliger à réécrire du code déja écrit. Je suis désolé mais je ne peux m'empécher de considérer que cela est du temps perdu.

Ce n'est pas parce qu'un développeur en particulier à mal choisi les méthodes qu'il voulait exposer que le principe l'encapsulation perds son intérêt.

Et même dans ce cas particulier, j'imagine que code java de la fft est suffisamment répandu pour ce développeur n'est pas jugé utile de l'exposer dans son API.

Le fait de ne pas exposer toutes les méthodes de ses classes permet au développeur de s'assurer que ses méthodes de classe ne seront pas appellées n'importe comment et dans n'importe quel ordre.
Et du coté de l'utilisateur de cette classe, ça lui évite d'avoir à se soucié justement de ces détails d'implémentation.

Citation:

---

Ce n'est pas parce qu'un développeur en particulier à mal choisi les méthodes qu'il voulait exposer que le principe l'encapsulation perds son intérêt.

---

Ben si justement, quant cela empeche tout autre fonctionnement.

Citation:

---

Et du coté de l'utilisateur de cette classe, ça lui évite d'avoir à se soucié justement de ces détails d'implémentation.

---

On peut aussi considérer que l'utilisateur est un grand garçon et qu'il peut être assez grand pour assumer les conséquences de ses actes, du moment que la façon d'appeler "officielle" est bien décrite.

Citation:

---

Envoyé par fredmn

Dans ce cas particulier, il ne pourra jamais supprimer la fft de son plugin, puisque le plugin calcule et affiche une fft. Ce qui me gène c'est que je ne peux pas calculer la fft, sans l'afficher.

---

Pas vraiment, un plugin pour ImageJ est à voir comme une boite noire où le seul point d'entrée et de sortie servent pour ImageJ uniquement.
Il n'y a pas à exposer d'autres méthodes car le plugin doit être uniquement utilisé au sein d'ImageJ, et rien ne garantit les résultats si on court-circuite le plugin.


Il pourrait y avoir des comportements indésirés dans le cas d'appel à une méthode public fft :
- non recentrage de l'image
- utilisation de cache pour optimiser le plan d'exécution (la fft est calculée plusieurs fois)
- l'appel à la fft nécessite éventuellement l'initialisation d'un contexte que tu ne peux pas maitriser


Par contre, rien ne t'empêche de reprendre les sources... Car rien ne l'aurait empêcher de sortir le vrai traitement métier du plugin... Mais il fallait que ce soit concu pour.

Citation:

---

Pas vraiment, un plugin pour ImageJ est à voir comme une boite noire où le seul point d'entrée et de sortie servent pour ImageJ uniquement.
Il n'y a pas à exposer d'autres méthodes car le plugin doit être uniquement utilisé au sein d'ImageJ, et rien ne garantit les résultats si on court-circuite le plugin.

---

Mais je suis sous ImageJ ! Mon seul objectif d'écrire un plugin qui calcule une fft en (pseudo) temps réel sur un flux vidéo en entrée (a des fins de démonstration). Je veux donc utiliser la fonctionnalité du plugin mais sans l'affichage parasite car je dois calculer plusieurs fft par seconde.

Citation:

---

Il pourrait y avoir des comportements indésirés dans le cas d'appel à une méthode public fft :
- non recentrage de l'image
- utilisation de cache pour optimiser le plan d'exécution (la fft est calculée plusieurs fois)
- l'appel à la fft nécessite éventuellement l'initialisation d'un contexte que tu ne peux pas maitriser

---

La dessus, je suis d'accord. Mais la seule question que je me pose est : pourquoi m'interdire aussi irrémédiablement la chose.

Perso je connais pas imageJ ma réponse se contente donc d'un point de vue objet.

La philosophie open source concerne la libre circulation du code source. Ainsi si un jour dans une méthode quelconque (même private) un bug est découvert, "n'importe qui" peut le corriger en allant modifier la méthode incriminé.
Ca c'est l'application en elle même.

Ensuite il y a l'utilisation de l'application ou plutôt de l'API.
Une API est une interface qui permet à une personne qui n'a aucune connaissance de l'implémentation de l'application d'utiliser des services fournis par cette interface.

Prenons un exemple : l'application contient une classe Image qui s'occupe de redimensionner une image. L'application contient une méthode publique "redimensionnerImage(hauteur,largeur)". C'est le service qu'elle propose.
Après dans la classe Image il y aura peut-être une méthode privée (ou N) qui vont s'occuper de faire les calculs, de choisir comment redimensionner etc..
Et ceci c'est l'implémentation, et ca l'utilisateur de l'API n'a aucunement besoin de savoir comment cela se fait, tout ce qu'il veut c'est redimensionner son image.

Citation:

---

Prenons un exemple : l'application contient une classe Image qui s'occupe de redimensionner une image. L'application contient une méthode publique "redimensionnerImage(hauteur,largeur)". C'est le service qu'elle propose.
Après dans la classe Image il y aura peut-être une méthode privée (ou N) qui vont s'occuper de faire les calculs, de choisir comment redimensionner etc..
Et ceci c'est l'implémentation, et ca l'utilisateur de l'API n'a aucunement besoin de savoir comment cela se fait, tout ce qu'il veut c'est redimensionner son image.

---

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.

Une API est un outil qui te permet d'effectuer des traitements. Si le traitement de prendre en entré une image, et d'afficher en sortie cette image traitée par fft, alors seules les méthodes permettant de proposer cette affichage doivent être public.

Il s'avère que dans ton cas, oui ca aurait été cool d'avoir directement la méthode qui calcul le FFT en public. Mais la spéc de cette API c'est d'afficher une image transformer, pas de calculer une transformer, donc il n'y a pas de raison de mettre public les fonctions de calculs. Peut être que la spec est mal faite, mais ce n'est pas le principe d'encapsulation qui est en cause.

Alors tu vas me dire, mais qu'est ce qui empêchait le type de mettre public la méthode de calcul. Il est possible (je ne fais que supposer) que la façon dont il l'a implémenté faisait que la fonction utilisait des variables qui sont initialisés ailleurs. Après peut être que d'avoir implémenter cette fonction de la sorte est une erreur de conception, j'en sais rien.


Edit : Pour ton exemple, oui en effet ca serait con de faire ca, s'il y'en a une mettre public c'est la 2ème. mais c'est parce qu'il y' a des exemples qui font que c'est con que le principe est mauvais :D

l'API est peut-être mal faite, pas pratique, buggée, inadaptée?... Mais ça reste propre au principe de l'API...

A titre personnel, si dans mes projets on devait mettre toutes nos méthodes public, on ne s'en sortirait pas !! Une API a des objectifs fonctionnels et seuls ces méthodes fonctionnelles doivent apparaitre...

Ils ont raison tous, moi je me moque de savoir comment le traitement est fait, et je n'ai pas envie d'y avoir accès ! :D :mrgreen:
C'est aussi une question de lisibilité, de clarté, et donc de simplicité.

Bon histoire de provoquer un peu, mais on discute entre nous hein ;o)

Citation:

---

Il s'avère que dans ton cas, oui ca aurait été cool d'avoir directement la méthode qui calcul le FFT en public. Mais la spéc de cette API c'est d'afficher une image transformer, pas de calculer une transformer, donc il n'y a pas de raison de mettre public les fonctions de calculs. Peut être que la spec est mal faite, mais ce n'est pas le principe d'encapsulation qui est en cause.

---

Pour autant que je me souvienne, le but de l'objet est de permettre la réutilisation des choses non? Si le fait d'utiliser "trop" d'encapsulation conduit à la possibilité de specs mal faite (dans le sens dont j'ai parlé précedemment), alors le principe de l'encapsulation est-il bon ? Ou pour moduler un peu, peut-être ne faut-il pas trop encapsuler ?

Citation:

---

Ils ont raison tous, moi je me moque de savoir comment le traitement est fait, et je n'ai pas envie d'y avoir accès !
C'est aussi une question de lisibilité, de clarté, et donc de simplicité.

---

Mouais, enfin a quoi cela sert-il d'avoir une api super-claire si au final on la bride ? Parce que au final, je suis aller chercher un tierce librairie, un peu rageant alors que tout est la au départ, potentiellement.

Citation:

---

Envoyé par Kanithael

A titre personnel, si dans mes projets on devait mettre toutes nos méthodes public, on ne s'en sortirait pas !! Une API a des objectifs fonctionnels et seuls ces méthodes fonctionnelles doivent apparaitre...

---

Et surtout un gain d'évolutivité !

Les méthodes privées ont un énorme avantage : on peut en faire ce qu'on veut sans que cela impacte QUE notre code !

A l'inverse toute modification sur la signature d'une méthode non-privé pourrait avoir d'importante conséquence sur toutes les classes qui hériteraient ou utiliseraient notre classe. En clair cela aboutit à une incompatibilité potentielle (source, binaire ou les deux selon les cas), ce qui au sein d'une librairie peut poser problème...

Citation:

---

Envoyé par fredmn

Pour autant que je me souvienne, le but de l'objet est de permettre la réutilisation des choses non?

---

Oui : les objets fournissent un service dont tu peux te servir. Mais tu n'as pas forcément à connaitre la manière dont ils travaillent et encore moins à t'immiscer là dedans !

Si la moindre classe devrait fournir publiquement le moindre code qu'elle utiles, on se retrouverait avec des classes énormes surchargés de méthodes inutilisé dans 99% des cas...


a++

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.