Je suis actuellement en train de faire joujou avec ImageJ et la webcam intégrée à mon netbook. Je teste ainsi la mise en oeuvre de traitements temps-réels. Comme je ne suis que rarement original, j'ai cherché à faire afficher en permanence la transformée de Fourier de l'image de la webcam. Si j'ai réussi à mettre au point les aspects acquisition et restitution, le traitement m'a posé problème.
Il se trouve qu'ImageJ possède un plugin intégré de calcul de la FFT. Le malheur est que la seule méthode exposée est une méthode qui calcule la FFT sur une image ET qui affiche cette FFT. Je ne désire pas cet effet de bord, qui viendrait perturber mon affichage personnel. Donc impossible d'utiliser le plugin. Cela est d'autant plus énervant qu'une méthode existe qui ne ferait que le calcul existe dans le plugin. Mais cette méthode n'est pas exposée, donc n'est pas utilisable. J'ai été obligé d'aller chercher un autre plugin pour faire le travail.
J'ai donc du mal à comprendre l'intérêt d'écrire du code et de le cacher ensuite. Je suis aller poster une question sur un forum, vous pouvez aller voir la discussion. Je trouve les réponses qui m'ont été données assez insatisfaisantes. En particulier celui qui consiste à avancer que le concepteur d'une API est seul apte à juger de l'utilisation correcte de son API.
J'ai fait un parallèle avec l'utilisation libre d'une librairie. En effet le principe sous-jacent au libre et de permettre l'utilisation non-bridée du code. Je trouve que le fait de déclarer des méthodes privées est contradictoire avec ce principe. Je comprends bien que la conception d'une spécification d'une API n'a rien a voir avec la licence d'utilisation de cette API. Mais il me semble qu'il y a une contradiction en intention.
Il existe des langages qui ne possèdent pas cette notion de méthode privée (je pense à python), et je trouve cela très bien.
FMN.
ps : il me semble que Paul Grahma Graham a écrit un truc la dessus, il faut que je le retrouve.
- Une sélection (automatique) de billets similaires :
- Image numérique et tableau : est-ce identique ?
- Représentation d'images (Clojure et Java), première partie.
- Représentation d'images (Clojure et Java) #2
- Utiliser ImageJ dans un notebook Sage, un exemple d'appel de Java depuis Python
- Plugin ImageJ minimal en Clojure: inverser une image
Je suis bien d'accord.
En Python, il y a une convention sociale qui veut que toute fonction qui débute avec "deux soulignés" est privée. Si le programmeur souhaite tout de même l'utiliser, libre à lui, mais s'il rencontre des problèmes il saura à quoi s'attendre!
(Il s'agit de Graham et non Grahma.)
Daniel, merci pour le signalement de la coquille.
La notion de "privé(e)" se place sur le plan technique et n'a rien à voir avec celle d'"open source" qui se situe sur le plan philosophique. On peut bien écrire une méthode privée dans un logiciel open source.
Ne pas rendre publiques toute les méthodes répond à des besoins, normalement bien connus de tout concepteur/développeur professionnel, dès lors que ce qu'il développe dépasse le stade de la page de code. Je ne les répéterai pas ici, sûr que le forum de discussion "developpez.net" y aura déja répondu.
Tout ceci n'empêche pas : - soit de demander au concepteur d'un objet d'enrichir son interface publique; - soit de le faire soi-même, non pas en recopiant le code (réflexe d'amateur), mais en créant une méthode publique dans l'objet (plugin, etc.) encapsulant l'appel à la(les) méthode(s) privées.
@PHID,
il m'est tres clair qu'il est techniquement possible d'écrire une méthode privée dans un logiciel open-source, ce qui arrive régulièrement. Mon argument n'est pas technique mais au niveau de l'intention. Tu peux relire mon avant-dernier paragraphe, qui est pourtant clair.
Je suis en tout cas amusé de la réaction très vive de "programmeurs professionnels" sur le besoin (sic) de méthodes privées. Il semble qu'un crime de lèse-majesté ait été commis. Pourtant des programmeurs professionnels utilisent des langages où cette notion privée n'existe pas (Paul Graham avec Common Lisp par exemple). Cela indique tout de même que cette construction n'est pas indispensable. Je pense qu'il ne faut pas assimiler "programmeur professionel" à "professionel de l'orienté objet".
Après, oui, il existe des solutions telles que celle que tu décris. Mais je déplore qu'elles nécessitent la réécriture de lignes de code, inutiles à mon sens puisqu'elle ne sont présentes que pour enrober. Ce genre de lignes nuisent à la lecture facile d'un programme (amha).
amicalement, Fred