J'aurais voulu savoir comment fait-on pour passer en parametre une fonction à une méthode ? (comment doit etre definie la méthode et comment doit etre fait l'appel ?)
 
En C, je sais qu'il faut un pointeur sur la fonction puis ensuite on passe ce meme pointeur en parametre à la fonction cible...Mais en Java, je vois pas trop comment ça peut se faire...  

qu'est ce que tu veux faire au juste. Faut penser object hein

1) oublie le C
 
2) voilà comment on fait dans un langage objet :
 
quand tu passes une méthode M1 en paramêtre à une méthode M2(dans un lange comme le C), ce que tu fais en fait, c'est donner un moyen à la méthode M2 de faire l'action M1. Bref, ce qui t'intéresse c'est d'avoir la possibilitée, au sein de M2, d'avoir "quelque chose" qui remplira le contrat défini par la signature de la méthode M2.  
 
Bref, tu as besoin d'un objet (le quelque chose) qui possédera une méthode bien précise, c'est à dire qui implémente une interface.
 
ex :
tu as une méthode calc() qui fait une opération et qui envoie le résultat.
 

 
maintenant, tu peux envoyer n'importe quel objet qui implémenter l'interface Sender à la méthode calc. Par exemple une classe qui fait juste un log sur la sortie standard, ou dans un fichier ou qui envoie un mail, ou qui envoie le résultat par SMS, ou qui le stocke en base, etc ... tu vois le principe...
 
juste un exemple :  

 
Je vois un peu pres le principe mais je pense qu'il y a plus simple non ? Comme j'ai pas encore vu les Interfaces à l'ecole, je prefere y aller doucement...N'y a t-il pas moyen de faire la meme chose sans interface ?
 

c pas une question d'y aller doucement ou pas, c'est une question de faire les choses convenablement. Si tu veux faire des trucs de genre, retourne faire du C et puis c'est tout

oui, tu prends uniquement la classe Calcul de benou et si tu veux changer le code, tu fais une sous-classe de Calcul avec ton propre code.
 
Par contre, tu n'as le droit d'utiliser cette méthode que jusqu'à ce que tu progresses en objet. Si tu reviens dans 1-2 mois avec ça, on te flingue.

ca sert à quoi de faire mal quand on sait faire bien ??    
 
si tu veux vraiment pas faire d'interface, tu modifie la méthode calc pour qu'elle prenne juste un paramêtre du type de l'objet qui possèdera la méthode que tu veux appeler dans la méthode calc, mais tu perds toute l'évolutivité du truc. c'est nul
 
enfin gref, le principe c'est de passer un objet en paramêtre (à la place du pointeur de fonction du C)

les interfaces, c bon
 
 
edit: merci benou

1/ personne à relever le fait qu'il mélangeait fonction et méthode?  (alors qu'on ne parle que de methode en java)
 
2/ si il faut on peut faire de la reflection

fontion, méthode, on a tous compris de quoi il parlait ...
 
d'ailleur, en java, le terme le plus approprié serait fonction
 

il connais pas encore les iterfaces et elles lui  font peur alors va pas lui parler de reflection

1a/ certes ben quite à lui apprendre quelque chose...
1b/ ha bon HA BON
2/ certes. mais si c'est pour donner des cours, je vais me faire prof au lieu de passer mon temps ici moi...

Benou > tout ça n'a rien à voir avec le C. c'est le concept même d'objet fonction. le C propose de passer des pointeurs de fonctions, mais pas d'objet, le C++ propose un operator() poura voir la synthaxe d'un appel de fonction, pour Python, une fonction est déjà un objet et il y a aussi __call__, en Lisp/Scheme, c'est direct. Dans cette histoire, le seul à faire des acrobaties avec un langage objet pour arriver à exprimer ça, c'est toi. Faut dire ce qu'il est : si on aime le concept d'objet fonction (j'en fait tout le temps), et bien Java est mal aisé pour l'utiliser.
Alors pas la peine de vanner un mec sur ses connaissances en C, ce que tu lui fais en 5 lignes de Java, il te le fait en 1 lignes de C

 
troll

oh putain, not again
 
(c'est pas la taille qui compte, mais la façon dont on s'en sert )

typiquement le truc qu'on dit quand on en a une petite

tu peux pas t'empecher hein ?    
 
où est ce que j'ai vané le mec ??  
Il pose une question, je lui donne la réponse ... bien complete en plus la réponse... Y a que toi pour trouver un truc à redire ...

 
T'as 15 ans de retard là. Economiser des lignes de code quand on programme, c'est fini!

tu veux voir?

dans mes ST magazine y'avait des concours pour faire des softs en 10 lignes maxi... y'avait des mecs qui faisait des jeux complets comme ça en gfa basic

un langage qui te permet d'exprimer naturellement un concept avancé, je ne vois pas où est le problème. ce que tu dis, c'est comme si tu parlais d'assembleur ...

 
Harko c pour ton dommaine là

et c'est parti pour un squatage hors sujet trollesque à souhait ...
 

t'as qu'a pas faire ce genre de réflexions

 
C vendredi

laquelle ?

 
Et ça à été Modo. Mon Dieu...

vos gueules

nan mais attend, j'aimerai bien comprendre à propos de quoi il e na après moi sur ce coup là ...

en meme temps vu une des moitiés de modo qui reste...

ben j'ai déjà justifié ...
bon je sors de toutes façons

ouais, et éventuellement évite de revenir ...

La différence c'est que java n'est prévu _que_ pour faire de l'objet, pas pour mélanger du fonctionnel avec.  
 
Il est d'ailleur assez mal venu de mélanger références sur des fonction, fermetures lexicales réelles, et opérateurs déguisés. Surtout que dans le tas c'est sûrement pas la solution qui est offerte par C/C++ qui s'en sort le mieux. De plus, quand on comence à foutre ça dans un langage qui possède (massivement) des effets de bord, c'est pas la peine de se retrouver à poil.
 
Mais bon c'est sur que quand on est un ha><or qui compte ses lignes de code, essayer d'y voir un peu plus loin que la grammaire, c'est un truc de faible.

putain, mais c'est quoi cette histoire de nombres de lignes ? vous êtes butés ou quoi ? vous êtes les premier à critiquer le C par ce que la gestion de char* est longue et fastidieuse comparé à des objets de types string, et vous êtes tous d'accord qu'un langage qui permet de manipuler de manière concise et élégante les chaines de caractères est bien meilleur sur ce point

Y'a que ta remarque était très très conne. Et qu'il faudrait pas que les débutants répètent ce genre de conneries.
 
Mélanger pointeur sur fonction, la surcharge du mauvais opérateur, et fermeture lexicale et justifier le tout par le nombre de lignes de code ou "l'intuitivié" (c'est vrai qu'envoyer un message à un objet c'est vraiment un truc contrintuitif en objet) c'est bien la preuve de n'avoir rien capté à l'histoire.
 
En particulier, reprocher à un langage de ne pas avoir avoir une fonctionnalité qui n'appartient pas à sa catégorie alors qu'il l'a (et à quel prix !) et donner en exemple 2 trucs qui _semblent_ l'avoir pour le débutant mais qui ne l'ont pas, je trouve ça très fort. T'aurais mieux fait de citer les crochets de smalltalk plustôt que de citer le langage de tes nuits humides sur ce coup là.

c'est quoi une "fermeture lexicale"?
(merci d'utiliser des termes simples pour l'explication et au besoin un exemple con et concret:D)

c'est un objet qui embarque avec lui toutes les variables visible à l'endroit où il est déclaré et chaque variable, embarque elle-même les variables qui sont visibles de son point de vue. Comme en général la visibilité est lexicale, on appelle ça une fermeture lexicale.
 
Pour y voir le rapport avec la choucroute, prenons un petit exemple une belle méthode non statique en C++, si on prend un ,pointeur dessus, ce qui est parfaitement légal, on va avoir du mal à l'exécuter, because il lui manque tout, jusqu'au this, elle n'embarque rien. Elle est complètement inutile. C'est pourquoi en C++ on évite de prendre des pointeurs sur autre chose que des trucs statiques, les variables globales qu'elle petu référence, sont, elles, accessible de partout (notez, pas "visibles", mais "accessible", le mot-clef "static" fait la différence).
 
En java, on a ces fameuses "inner-class" qui sont beaucoup plus qu'elles n'y paraissent, leurs instances n'existent que dans le cadre d'une instance de la classe englobante. En réalité, la classe interne embarque une référence sur l'instance englobante, embarquant du coup, ses variables d'instance et celle de sa classe englobante. C'est logique, les variables de l'instance englobante sont accessibles dans les méthodes de l'instance interne. Les variables statiques, sont, comme en C++ accessibles de n'importe où.  
 
Plus loin : une méthode peut être définie dans une autre méthode auquel cas elle a accès à tout ce qui est visible au point de définition. Et ça se complique, car l'existance des variables locales de la méthode englobante au moment de l'accès depuis l'instance interne n'a rien de garantie. C'est pourquoi elle vont être embarquées (par copie) et qu'elles doivent être "final" (pour être sûr qu'il s'agit bien du même objet dans la méthode englobante et englobée, c'est une garantie que n'offrent pas naturellement les effets de bord sinon).
 
 
Les langages fonctionnels embarquent simplement le contexte en copiant toutes les variables visibles dans un tableau (ils sont téhoriquement sans opérateur d'affectation).

bon je crois que je vais devoir relire tout ça