Bonjour,
 
Suite à de nombreux topics créés par des débutants en java, et sous l'impulsion de mon exaspération, j'ai décidé de créer ce topic, qui a pour but de devenir un passage obligé pour tout débutant en java passant par ici.
 
Nous aborderons quelques sujets de base, et éviterons toute discussion/flamewar inutilement longue. Je tâcherai d'éditer les premiers posts pour les tenir à jour.
 
Sujet abordés:
 
* Tutos / réferences : quelques bons liens vers de la bonne documentation accessible. Pas questions ici de dupliquer le topic javafaq/bibliolinks, soyons efficaces, soyons bref; nous n'y mettrons que l'essentiel pour bien débuter.
 
* Comment débuter en Java, pourquoi il ne faut pas commencer avec un IDE.
 
* Mini-FAQ, ou comment résumer en un post 50% des questions de débutants posées ici.
 
* Les bons réflexes pour aller plus loin.

Tutos / réferences :
Ici, quelques bons liens vers de la bonne documentation accessible. Pas questions ici de dupliquer le topic javafaq/bibliolinks, soyons efficaces, soyons bref; nous n'y mettrons que l'essentiel pour bien débuter.
L'anglais sera de rigueur pour beaucoup de ces références. Comme le dit Nasser Kettani, Le premier langage à apprendre pour programmer, c'est l'anglais. (Ce qui, au passage, ne dispense pas non plus d'écrire le français correctement)

* Tutoriels
- les inévitables tutoriels de Sun, généralement assez bien faits : http://java.sun.com/docs/books/tutorial/ Couvrent beaucoup de sujets, anglais de rigueur. (Premiers pas en Java : de l'installation à l'execution d'un HelloWorld - table des matières complète)
- Thinking In Java et Penser En Java (Traduction en français) : Excellent bouquin, dispo gratuitement sur le net.

* Références
- La Javadoc: in-dis-pen-sable ! http://java.sun.com/j2se/1.5.0/docs/api/ (pour 1.4 et pour 1.3) S'il le faut, on expliquera comment s'en servir. ( La plupart du temps, le nom d'une classe dans google mène droit à la javadoc correspondante)
- Les conventions de codage et de nommage : Tres important à suivre. (A fortiori ici, puisque ça permet à quelqu'un qui ne connait votre code de "rentrer dedans" beaucoup plus facilement). ( A ce sujet, merci d'éviter les horribles mélanges anglais/français dans votre code) Trois règles de base: 1) Un nom de classe commence toujours par une majuscule, si le nom la classe comporte plusieurs mots, on alterne majuscule/miniscule; exemple: BindingService - 2) Les variables commencent par une minuscule, exception faite pour les constantes qui sont entièrement en majuscules - 3) Une méthode commence toujours par une miniscule. Si le nom de la méthode comporte plusieurs mots, on alterne miniscules/majuscules:
exemple: getRelatedData(). D'autre part, les noms de classes et les noms de variables sont des noms communs génériques, les méthodes des verbes (plutôt d'action).
- Java Notes. These Java programming notes are written to fill in missing or weak topics in textbooks that [the author has] taught from. Many pages are useful for reference, but not as an ordered tutorial. Some pages are still rough drafts, but [the author is] slowly working on fixing them.[/url]
- Java Basics.[the author has] started writing a more coherent tutorial called Java Basics. In addition to lessons, there is also commentary which explains why things are done the way they are.
 
- La FAQ de developpez.com
- Tout ce que vous avez toujours voulu savoir sur le CLASSPATH
- Le topic sur les Exceptions (à valider)
- Google : eh oui ! Devant un message d'erreur abscon, google pourra vous aider, et cela évitera un tas de topics inutiles et redondants.

Comment débuter en Java
... et pourquoi il ne faut pas commencer avec un IDE.
 
* Quelqu'un se dévoue pour écrire un truc simple sur l'installation propre de java?
 
* Avec quoi j'édite mes sources?
Nous sommes quelques valeureux vieux cons ici à croire fermement que pour débuter, il vaut mieux éviter les IDE (Integrated Development Environment). On conseille donc un simple editeur de texte genre Context, jEdit, ultraedit, ou autre, et un shell pour commencer. Cela permet de vite comprendre les méchanismes sous-jacents de java, le classpath et ce genre de choses - certes, au prix de quelques frustrations parfois - ce qui évitera à terme de tomber le bec dans l'eau quand l'on voudras sortir l'appli de l'éditeur. (Parce qu'en général à ce moment là, on a justement plus envie de se prendre les pieds dans des trucs de débutant)
 

Mini-FAQ
* JRE, JDK, J2SE, J2EE, J2ME, chuis perdu !
Alors, un petit résumé:
JRE : Java Runtime Environment : ça sert, comme le nom l'indique, à éxécuter des applications écrites en Java.
JDK : Java Development Kit : ça sert, comme le nom l'indique, à développer des applications en Java. Inclus une JRE.
J2SE : Java 2 Standard Edition : si vous commencez Java, c'est ce qu'il vous faut.
J2EE : Java 2 Enterprise Edition : J2EE est une "extension" de Java, composée de multiples APIs (EJB, JMX, JTA, et bien d'autres). A priori, il n'y a pas besoin de l'installer, contrairement à ce que l'on pourrait croire. Installez-vous un serveur d'application, et les jar nécessaires sont fournis. Vous pouvez bien entendu "télécharger J2EE", mais je conseillerais de ne rien "installer", mais simplement d'utiliser les jars fournis (voir topic classpath)
J2ME : Java 2 Micro Edition : une version "réduite" de Java, pour les appareils mobiles. (Téléphones, PDAs, ...)
 
* Comment installer la librairie XYZ?
En java, une libraire est, la plupart du temps, constituée d'un simple jar. Il suffit donc de mettre celui-ci dans votre classpath, grace à l'une des nombreuses méthodes décrites dans le topic idoine. (Voir plus haut)
 
* Lire/écrire dans des fichiers
Rapportez vous au tuto de Sun sur les i/o. En deux mots, pour lire ou écrire des chaînes de caractères, utilisez Reader/Writer et leurs implémentations; pour lire ou écrire des données binaires, utilisez InputStream/OutputStream et leurs implémentations. A partir de la jdk1.4, il y a aussi le package java.nio - si quelqu'un veut l'introduire en 2 mots ici...
Il est aussi souvent question de "logger" ce que fait votre application: dans ce cas, ne perdez pas votre temps, et utilisez l'api de logging de java (à partir d'1.4) ou log4j (il existe d'autres api de logging)
 
* Lire des *resources*
Un petit lien qui explique comment accéder à des resources dans le classpath (vu que la question revient régulierement et que le topic classpath n'en fait pas mention): http://java.sun.com/j2se/1.5.0/doc [...] urces.html
(TODO : expliquer que fichier != resource)
 
* NoClassDefFoundException, NoClassDefFoundError ??
Rapportez vous au topic classpath: soit votre classe principale ne peut être trouvée par Java, soit il manque un jar sur votre classpath.
 
* ... cannot be referenced from a static context !?
Vous essayez probablement d'appeler une méthode d'instance depuis un "contexte statique", le plus souvent votre méthode main. Renseignez-vous sur la signification du mot clé static.
 
* NullPointerException !?
Vous essayez vraisemblablement d'appeler une méthode sur un objet non initialisé, ou vous passez une réference nulle à une méthode qui ne peut l'utiliser. En lisant la stacktrace attentivement, vous devriez trouver facilement l'origine du problème. (Classe et n° de ligne dans le code source)
 

Les bons réflexes pour aller plus loin
* Se réferer à la javadoc (cfr ci-dessus pour les liens)
* Maîtriser l'anglais
 

Merci de garder ce topic propre, d'éviter les débats, utiles ou pas: gardons ça pour les topics qui ont amenés à la création de celui-ci, afin de le garder succint et d'ainsi éviter de rebuter notre cher ami le débutant.
 
Que ceci ne vous empêche bien sur pas de contribuer à ce topic ou de proposer des améliorations

... j'aurais pas cru ca de toi
 
pour contribuer, des idées de questions récurrentes :  
 
- expliquer la NPE, et les coups classiques qui la provoquent (objet déclaré mais pas initialisé, etc...)
- mettre un lien vers les dessous de string

bah c'est normal, c'est l'ordre pour faire les choses.
 
 
au moment de leur premier déploiement, ils tombent sur leur premier pb de déploiement.

Les "exceptions"
 
Qu'est-ce qu'une exception ?
Une exception est un moyen dont dispose le programmeur/le système pour signaler qu'un problème est survenu.  
On distingue 2 types de problèmes : les exceptions, et les errors.  
- Une erreur est un problème grave, qui conduit à un crash irrécupérable du programme, comme par exemple la OutOfMemoryError : le système ne dispose plus de mémoire disponible, et crashe
- Une exception : une exception est une erreur raisonnablement prévisible,qui ne nécessite pas forcément l'arret du programme. Par exemple, imaginez un formulaire où vous demandez l'age d'une personne. Il est évident que le nombre entré doit être positif. Si pour autant la personne rentre un nombre négatif, ou irréel, ou autre chose qu'un nombre, il vaut mieux afficher un message d'erreur que de terminer le programme. Les exceptions sont un méchanisme qui permet cela.
 
Il faut distinguer 2 grandes catégories d'exceptions : les exceptions filles de RuntimeException, et les autres.  
Lorsqu'une écrit une méthode susceptible de générer une exception (la méthode traitant le formulaire dans mon exemple), toute autre méthode utilisant la première méthode doit "catcher" l'exception, c'est à dire utiliser un bloc try/catch/(finally) pour indiquer au programme ce qui doit se passer si une exception est générée. Ce try/catch est obligatoire pour toutes les exceptions, sauf pour les RuntimeException, pour lesquelles il est facultatif.
 
Note : on ne "catche" pas les errors
 
 

• La NullPointerException

Cette exception est aussi connue sous son nom abrégé, NPE. C'est une exception très fréquente.
 
Considérons le code suivant :  

 
Lors de son exécution, il produit le code suivant
 

 
Ce message s'appelle un stacktrace, c'est à dire qu'il retrace toute les méthodes qui ont été appellée durant l'exécution du morceau de programme qui a conduit à l'exception.
 
Comment lire un stacktrace ?

Indique une exception, qui a eu lieu dans le thread Main
Le plus intéressant est le java.lang.NullPointerException : il indique le type de l'exception, ici une NPE
 

Ce bloc se lit de bas en haut : la première méthode appellée est donc la dernière de la liste, et la dernière méthode appellée est celle tout en haut.
Toutefois, si cet ordre a été retenu, c'est parce que c'est souvent la dernière méthode appellée qui génère l'exception.

Ici il faut lire que la méthode main de la class Test du package com.jubijub a été appellée. Le (Test.java:12) indique qu'il y a eu un problème à la 12ème ligne du fichier source Test.java (qui est donc le fichier source qui a servi a générer la classe Test.class)
 
A partir du moment où on utilise un éditeur de texte, il est donc facile de repérer la 12ème ligne, pour chercher d'où vient le problème. Si vous utilisez un IDE, le texte entre parenthèse ou la ligne entière sont généralement cliquable, ce qui permet de se rendre directement a l'endroit voulu.
 
Revenons au code :  
La ligne fautive est la suivante :  

 
Quel est le problème ?
Une nullPointerException signifie que vous essayez d'utiliser un objet référencé par un pointer nul, autrement dit que vous essayer d'utiliser quelquechose qui n'existe pas.
Pour comprendre cela, revenons au modèle objet : un objet dispose d'attributs, et de méthode. Pour pouvoir accéder à un attribut, ou utiliser une méthode, il vous faut une référence valide vers une instance de l'objet en question, et ensuite appeler la méthode désirée de cet objet.
 
La NPE vous indique en l'occurence que la référence qui pointe vers votre objet pointe vers null, autrement dit votre référence est invalide. Vous demander donc à du vide de faire quelque chose, ce qui est impossible.
 
Si on regarde la ligne, il faut regarder toutes les instances d'objet : on ne voit que name. Le code essaye d'afficher la longueur de la String référencée par "name". La NPE indique donc que name est vide.
 
Comment le résoudre ?
Si name est vide, ca qu'il est mal initialisé. On peut initialiser un objet de 2 façons :  
- en appelant un constructeur :  
Integer number = new Integer(2);
- par le résultat d'une méthode
number = myList.length();
 
Une NPE vient très souvent de 2 raisons :  
- vous avez oublié d'appeller le constructeur :
Integer number; // number ne contient rien
- la méthode que vous appellez ne renvoit rien
String lastName = person.getName(); // en apparence tout va bien, mais si l'attribut name de person vaut null, lastName sera null aussi.
 
parfois vous aurez à remonter une chaine de méthode qui s'appellent avant de trouver laquelle renvoit null au lieu de ce qu'elle devrait renvoyer.
 
Si on revient au code, on constate :  

name est initialisé avec ce que contient l'index 1 du tableau nameList. Un tableau a son index qui commence à 0, donc le 1 représente "la deuxième case". Cette case contient null. Donc name vaut null.
 
L'erreur est trouvée, il n'y a plus qu'à corriger.
 
PS : cet exemple est bidon, mais il montre simplement un enchainement de problème.
PPS : si vous faisiez nameList[4], vous auriez droit à l'autre erreur classique : la ArrayOutOfBoundException, qui indique que vous demander un index en dehors des limites du tableau
 

PS : tapez pas trop fort
 
J'ai essayé d'expliquer :  
- en gros les exceptions
- comment lire un stacktrace (ce qui sert toujours)
- la méthode de recherche de la cause d'une NPE
 
PS : mon chapitre sur l'objet est fumeux, très améliorable

jubi > si l'article est si long, je serais d'avis d'en faire un topic et de le referencer ici, alors

il manque le dernier chapitre...  
comment catcher (attraper) l'exception et traiter la cas...
et aussi expliquer a quoi sert le finally

non je ne pense pas !
ce qu'il a dit est juste et a toute sa place ici...

A mon avis jubi tu as cherché à trop en dire et c'est trop condensé. Pour un newbie total, je suis pas sur que ton explication sur les exceptions soit très compréhensible. En même temps il y a déjà plein de docs pour expliquer ça, il aurait peut-être été plus judicieux de se concentrer sur le point de détail que tu voulais évoquer : qu'est-ce qu'une NPE, d'où ça vient et comment les repérer facilement.

ca devrait surtout etre découpé en 3 parties

Jubijub > vire un peu cet immonde code auto-généré
 

 
On vient de dire de ne pas utiliser d'IDE
 

 
C'est bien entendu incorrect - je suppose que tu as voulu trop simplifier. Il est bien sûr possible et souvent souhaitable de laisser l'exception se propager.
 
Par contre, j'insisterais lourdement sur la pratique à prohiber du catch and burry :

 
C'est acceptable dans des cas tout à fait exceptionnel, et ça s'accompagne toujours d'un commentaire adéquat dans le catch.

ben soit tu la catche, soit tu la throws, mais tu peux pas te contenter d'utiliser la méthode ...mais tu as raison, c pas clair...

 
surtout qu'une NPE, faut deja savoir quoi en faire

Disons qu'en précisant, le newb sera sans doute encore plus confus, mais ce sera plus correct.
 
+1 chrisbk -> l'exemple de la NPE pour aborder les exceptions en général n'est pas vraiment adéquat. Les cas de "catch" d'un NPE sont plutôt rares, et certainement à proscrire chez un débutant.
 
Sinon, je vois déjà d'ici :
 

 

 
Edit : sinon, pour le petit chapitre.

Je te livre tel quel ce que j'avais écrit quand j'avais eu le courage de commencer le topic javafaq² et que j'ai jamais pris le temps de continuer :  
 
----
 
Ce topic référence les liens les plus utiles pour la programmation sur Java. Quand vous avez une question, merci de vérifier si la réponse ne se trouve pas à la suite d'un de ces liens
 
1. Les liens pour débutants
 

• Premiers pas en Java : de l'installation à l'execution d'un HelloWorld
• Le tutorial Java et un index avec tous les tutoriaux Java de Sun.
• Le Java Developpement Kit (JDK ou J2SE SDK) v1.4, v1.5 : contient le compilateur et l'environnement d'execution Java (JRE).   ne pas se tromper de lien : "Download J2SE SDK" ou "Download JDK"  
• La javadoc v1.2, v1.3, v1.4, v1.5. Indispensable. La plupart des réponses se trouvent là !
• Thinking in Java en anglais et en français : Très bon bounquin, gratuit.
• Les conventions d'écriture. Très importantes en Java. prenez de bonnes habitudes dès le début
• google. On trouve la réponse à la plupart des questions avec une simple recherche (essayez avec les messages d'erreurs par exemple)

2. FAQ divers
 

• developpez.com FAQ très complète en français
• jGuru

Un petit quelque chose sympa et bien expliqué sur la généricité c'est prevu ? (genre avec plein de <? super <? extends E>> )

c'est pas trop pour débutant ca ...

non, c'est complexe en soi, donc pas d'explication simple.

 
Je rajouterai  

• Java Language Specification : en anglais
• Java tutorial - The really big index : en anglais

le premier parce que , et le second parce que l'index est bcp plus détaillé

Benou, merci pour les liens, je mettrai ça à jour dans la journée.
Jubi, pour le truc des exceptions, je pense vraiment qu'un topic à part serait plus approprié.
Pour le nettoyage, je laisse le soin à chacun de voir avec sa conscience (et mon pied dans la gueule)

 
nan mais dans la réalité :

 
(la clef, c'est "exitVM" ).

Comme on voit assez souvent des erreurs de convention d'écritures dans le code copier/coller de nos débutants , on peut peut-être donner les 3 règles de base :
 
1. Un nom de classe commence toujours par une majuscule.
si la classe comporte plusieurs mots, on alterne majuscule/miniscule :
exemple BindingService
 
2. les variables commencent par une miniscule,exception faite pour les constantes qui sont entièrement en majuscule.
 
3. Une méthode commence toujours par une miniscule.  
si la méthode comporte plusieurs mots, on alterne miniscule/majuscule :
exemple getRelatedData()
 
D'une manière générale évitez  les noms fantaisiste, cherchez à être le plus fonctionnel possible(le couple getXxxx/setXxxx, pour un booléen setXxxx,isXxxx   etc...)
 
Bon c'est basique mais c'est déjà un bon départ pour écrire du code lisible.Pour aller plus loin regarder le lien de Jubijub sur les conventions.
 
En cas j'éditerais pour étoffer un peu ...

- Un petit mot aussi sur les immondes mélanges français/anglais, sans mentionner les accents dans les noms de variables.
 
- Comment éviter le piège du main static. Bcp de débutants commencent à taper du code dans la méthode main. Comme le contexte est static, il faut faire appel à des données membres static. Et c'est l'engrenage infernal.
 
Si cette remarque paraît utile, je peux développer.

D'autre part, les classes sont des noms communs génériques, les méthodes des verbes (plutôt d'action, sauf "to be" ) les noms des variables sont des noms communs aussi.

Ce topic serait-il tombé dans l'oubli ? Tout en bas de la page 3, Wow...
 
Vos commentaires sont les bienvenus, en MP au besoin. J'apporterai les corrections nécessaires sans doute dimanche.
 
Le piège du static void main
 
Alors que j'étais débutant, je suis tombé, comme pas mal d'autres, dans un piège classique qui peut s'avérer très néfaste. Le nainternet n'était pas encore très répandu, je ne fréquentais pas ce forum et je n'ai pas eu la chance de me prendre un bon coup de pelle à clous pour me remettre les idées en place. Résultat : je me suis un peu fâché avec Java avant de revenir à de meilleures considérations, non sans avoir perdu pas mal de temps et avoir dû remettre à plat le peu de connaissances que j'avais acquises.
 
Ami lecteur, je te propose de suivre avec moi le cheminement de ce piège insidieux mais bien réel, et d'en décrypter les mécanismes pour mieux l'éviter.
 
Après avoir potassé le présent tutoriel, bouquiné quelques références et avoir lu avec attention tous les topics proposés, tu commences à te débrouiller et à écrire de petits programmes en Java. Le classpath ne te pose plus trop de problème. Tu as passé le stade du "Hello World" et le nombre de lignes de ton programme devient conséquent.
 
Tu décides de réaliser un premier programme ludique : un jeu de petit bonhomme pendu.
 

 
Tout ceci n'est évidemment pas modulaire, outre le fait que l'approche est certainement purement procédurale et peu orientée objet. Tu décides de découper ton programme en petits morceaux, plus modulaires et plus lisibles. Pour ce qui est de l'O.O., on verra plus tard.
 

 
Outre le côté O.O. qui fait très certainement défaut, mais qui dépasse le cadre de ce tutoriel, une splendide erreur te saute directement au visage, préparant le piège mortel :
 

 
Un tentative de supprimer les "this" dans la méthode "main" aboutit à un résultat similaire :
 

 
Ainsi, une variable "non static" (playerName, difficultyLevel) ne peut pas être référencée depuis un context "static" (la méthode main) ? Qu'à cela ne tienne, rendons ces variables "static", et ça devrait marcher :
 

 
Cette fois, ça passe pour assigner les variables, mais ça cale sur startGame() :
 

 
Encore ce problème de static. Baah, yaka rendre startGame() static elle aussi, non ?
 

 
Et voilà, ça marche ! Ca te paraît bon ? On laisse le code comme ça ?
 
Si tu as répondu "oui", ou si tu as déjà utiliser un artifice simialire, tu es tombé dans le piège du static main. En rendant une première variable static, tu as continué avec les méthodes de la classe. La gangrène s'est propagée à d'autres classes, car le même problème se posait, si aisément résolu par le mot magique "static".
 
En fait, ton programme est rigoureusement anti-O.O., est très peu modulaire et ne sera pas évolutif. Une véritable horreur. Il n'y a pas le moindre objet dans cette histoire. Nous avons fait un usage incorrect de "static". Ce faisant, chacune des données membres (playerName, minLetters, ...) seront partagées par toutes les instances de la classe. Si je veux intégrer ou réutiliser tout ou partie de ce code, il y a fort à parier que je ne saurai pas en faire grand chose.
 
Mais alors, on m'aurait menti ? Qu'aurais-je dû faire ?
 
- Ne pas utiliser abusivement le mot clé "static" uniquement parce que ça permettait de compiler;
- Déclarer un objet "BonhommePendu" et l'instancier;
- Appeler les méthodes sur cet objet, et non pas sur la classe, comme c'est le cas avec static.
- Accessoirement, ne pas oublier l'adage "touche pas à mes attributs, passe par une de mes méthodes", et ne pas accéder directement aux données membres, mais faire appelle à un accessor.
 
Un exemple vaut mieux qu'un long discours :
 

 
Et voilà !
 
Bon, c'est pas encore le top au niveau de l'O.O. et de la modularité, et ça n'empêchera pas nraynaud de t'asséner quelques coups de pelles à clous. Mais c'est déjà nettement mieux, et tu viens d'éviter de filer un mauvais coton en O.O. dès le départ et de te prendre une mauvaise habitude. Rassure-toi, Java réserve d'autres surprises, qq soit le niveau.
 
 
 

il y a une version plus recente de think in java, en français
 
voila

/!\ Merci de ne pas polluer ce topic par des posts hors sujet /!\

un ptit nettoyage?

A ma demande, un modérateur va donner un coup de balais à ce topic. Merci de ne pas polémiquer

 
, si on est pas sous un IDE, on est pas productif

il manque l'explication des interfaces, ... quand g t noob en java, venant du C, g t perdu sans mes pointeurs de fonctions

un débutant, je lui demande pas d'être productif avant de lui demander de comprendre ce qu'il fait.

Poste un bon petit paragraphe bien tassé, 1 ou 2 liens bien foutus, je me ferai un plaisir de mettre les premiers posts à jour

 
euh, j'ai soulevé le problème ... maintenant le faire c'est une autre histoire (pb de temps). Sinon je pense qu'il y a moyen de faire un bon copier/coller d'un site sur les interfaces en java, c'est rapide et facile  

Les interfaces
 
Une interface java est un type de données servant de modèle que des classes peuvent choisir de suivre. On parle alors de classes qui implémentent telle ou telle interface. Une classe peut implémenter plusieurs interfaces. A quoi cela-sert-il ? En définissant une interface, nous pouvons coder des comportements communs à des classes qui à priori n'ont rien en commun. Cela permet également de séparer la spécification du codage à proprement parler.
 
En tant que modèle pur, une interface ne contient pas de code mais uniquement les prototypes des méthodes qu'impose le modèle. Prenons un exemple:
 

 
Nous avons défini une interface "Mangeable". Il y a deux méthodes qui caractérisent l'interface. Vous allez vite comprendre l'interêt par la suite.
 
Parlons implémentation: les classes voulant se plier au modèle "Mangeable" doivent implémenter chacune des méthodes de cette classe, c'est à dire en fournir le code. Rien ne vous empêche par ailleurs de ne pas en metttre (comme c'est le cas dans la famille des classes Adapter de awt.event mais c'est une autre histoire). L'indispensable, c'est à dire ce que le compilateur impose, c'est de redéfinir les méthodes. Imaginons deux classes:
 

 
A priori ces classes n'ont rien en commun niveau codage mais on sent bien qu'elle sont sémantiquement proches (). Laissons opérer la magie des interfaces. Nous allons implémenter l'interface "Mangeable" avec ces deux classes Patate et Radis en utilisant le mot-clé implements, le principal étant de redéfinir les méthodes manger et aCuire.
 
 

 
 
Vous commencez à saisir le truc. En implémentant l'interface "Mangeable" dans ces deux classes, nous en avons fait des sortes de cousines. L'interface étant un type de données au même titre que les classes, nous pouvons écrire des algorithmes souples et élégant avec ces types.  
 
Attention toutefois: une interface ne peu pas s'instancier, cela n'a pas de sens A l'éxecution, ce sont des classes qui implémentent l'interface qui seront utilisées.
 
Nous pouvons imaginer ceci:
 

 
Et voila