J'ai un souci avec les paquetages Java. Comment les fichiers d'une même application sont-ils compilés ? Combien de fichiers en résultent-ils ? Pour les paquetages, quel est le résultat ?

logiquement, quand tu programmes en JAVA, tu fais un ficher source par objet, t'as donc, après compilation, un fichier .obj par objet.
et pour les paquetages, je vois pas trop ton pb...tu t'en occupes pas, tu les importes quand t'en as besoin, c'est tout !

Certes, mais j'ai un gros projet en chemin, et j'aurai certainement à créer des paquetages perso. Comment dois-je procéder pour bien faire ?

Il me semble que le compilateur fournit un fichier '.class' par classe

non non non !  
tu as un fichier .class pour chaque classe de ton programme. ça pourrait correspondre a ton nombre de fichier, si si dans un fichier tu as creer une classe interne comme pour les listeners (c tres probable) tu auras dexu .class resultant.
en gros : 1 .class pour chaque classe (interne ou pas)

Pour l'histoire des fichiers je suis d'accord : dans mon bouquin j'ai trouvé une remarque similaire. Cela dit je ne trouve rien concernant les packages, les méthodes d'accès associées pour des packages perso.

mais tu veux savoir quoi a propos des paquetages ?

 
.jar ?

Pas jar, package.
 
En fait, quandd tu créé la classe, tu met dans le fichier la déclaration du packge laquelle est est.
 
Ensuite, c'est une info qui est va etre convertie en répertoire
 
soit la classe suivante, toto.java

 
Quand tu va le compiler, le compilo va créé un repertoire coincoin, et mettre le fichier toto.class dans ce répertoire.
 
Donc, un pacjkage java => un répertoire.

[edit]--Message édité par kadreg--[/edit]

Bah oui. Un package permet de découper un projet en sous-projets. Tu bosses sur un jeu, tu va faire un package moteur3D qui cointient le moteur 3D, un package moteurSon, qui contient le son, et un package Jeu, qui va utiliser les deux premier.
 
C'est l'équivalent des namespaces en C++.
 
Dès que tu dépasse une certaine taille de projet, il faut pas hésiter à sous-découper afin d'ordonner le tous.
 
Et en java, les fichiers class sont regroupés dans des répertoires par package.
 
Ouvre le fichier rt.jar dans winzip, tu verras cette structure en répertoire.

Et on peut vraiment découper comme on veux ? J'aimerai savoir si on peut penser la structure du programme avant de commencer à l'écrire. Il faut pas que je me plante là-dessus !

Le but n'est pas de découper pour le plaisir de découper. Le but est de découper en projet en sous ensembles plus petits, avec des dépendances limitées entre elles. Un projet grandissant, il faut faire ce genre de découpage. Pourquoi ?
 

 
- Un sous-projet est plus simple à visualiser dans son ensemble que le projet complet. On travaille sur des informations plus petites.
- Cela permet une meilleure division des taches. Quand tu es à 10 sur un projet, chacun se prend un package, et on avance en parralèle. De plus, en cas de dépendance de packages.
- En cas de modification, on limite les impacts (enfin théoriquement, c'est pas toujours le cas )
- On a des chapitres pour documenter (et l'air de rien, c'est vachement important).
- On a tendance à écrire un code plus propre.
 
Ensuite, ces packages UML, on va généralement se les mapper en packages java. On peut parfaitement tout mettre au même niveau et se limiter soit-même à ce que l'on fait, mais le langage dispose d'une fonctionnalité permettant de le descendre au niveau du code, on ne va donc pas se priver.
 
Et c'est dans ces packages que l'on va mettre des classes, comme ici dans le package Moteur3D :
 

 
 
Maintenant, comment découper ?
Piouuuu, ca fait vivre pas mal de consultants ça. En fait, il n'y a pas de méthodes magiques pour le faire. Mais le découpage se doit d'avoir quelques caractéristiques.
 
- Chaque package correspond à un sous projet clairement identifiable dans ses fonctionnalitées.
- Chaque package ne peut être découpé en sous packages sans rentrer en conflits avec d'autres règles.
- Les packages sont liés entre eux, mais sans cycles d'interdépendances. En cas de cycle, c'est que l'on a coupé un truc en deux qui n'aurait pas du être coupé.
- Le découpage doit être proche du fonctionnement interne de l'application (Ca semble con, comme ça, mais réaliser une application d'une façon, et l'organiser d'une autre, c'est MAL (c)).
 
 
Ce que je peux te conseiller, c'est de commencer en utilisant un AGL UML pour découper ton application en package/classes (pour faire du dessin, y'en a des gratuits qui marchent bien). Et une fois que tu as un bon découpage, tu te l'affiche au mur.
 
Moi, je suis très UML (ca se voit), va voir sur uml.free.fr pour plus d'infos sur la notation, mais si tu utilise que package et classes, c'est pas utile d'aller trop loin.

kadreg>
Bon j'en profite pendant que ça parle d'uml.
T'aurais pas un logiciel qui a partir du source c++ ou java te donne les diagrammes uml. parce que j'ai un assez gros projet et je commence à m'y perdre parmis toutes les classes.

en résumé, il fo découpé avec une certaine logique choisie au départ... Et tu te rendra vite compte si ton découpage est judicieux ou pas... Car si le developpement d'un module revient a developper trop de choses en meme temps c que ton decoupage est a revoir..  
Le tout c de garder a l'esprit le dictons premier : Diviser pour regner

 
Pas mal d'agl disposent de cette fonctionnalité. Objecteering, Rose, et Together le font (sort la mastercard).
 
Une remarque, tu ne va obtenir que les diagrammes de classes UML, il y a quantité d'autres diagrammes qui existent en UML, permettant de modéliser pas mal d'autre choses, mais que l'on ne retrouve pas dans le code.
 
Une autre remarque, faire comme ça, c'est mal. Pour un projet, mieux vaut utiliser des systèmes model-driven (du model UML dans l'AGL vers l'application) ou round-trip (un ensemble d'outils partageant le travail, chacun travaillant sur ses fonctionnalité).
 
L'utilisation d'un reverse pour documenter, c'est généralement de l'appel au secour

Bah oui, c'est mon premier gros projet, alors j'ai eu du mal a tout envisager du premier coup, alors j'ai que des p'tits dessins sur papiers et comme on est plusieurs le format numérique serait bien utile. Le diagrame hierachique me suffirait, tes schemas tu les a fait avec un des logiciels que tu m'as cité?

Celui qui te suffirait, c'est le "static class Diagram", les deux diagrammes que j'ai mis sont des Static class diagram.  
 
Il a été réalisé avec un des outil que j'ai cité (Together pour ne pas le nommer), mais c'est par ce que c'est le seul dont j'ai une démo qui marche à la maison, c'est vraiment pas celui que je connais le mieux. Mais attention, la demo ne permet pas d'enregistrer des diagrammes (ce que tu voit, c'est des captures d'écran croppées).

J'avais bien pigé que le découpage en package était une affaire compliquée. Mon appli s'étalent sur plusieurs écrans. Chacun étant affiché à tour de rôle (en principe). Quand on entend "proche du fonctionnement". Est-ce qu'un découpage par fenêtre est judicieux ?

 
Ce serais le pire découpage possible .
 
Je conseille plutot de faire un premier découpage provenent du pattern MVC (me souviens plus de ce que ca veut dire ).
 
Un premier package (core) contient le noyau de l'application. Les données, et les traitements bas niveau des ces données, comme les manières de les lier entre elles.
 
Un second contient la logique applicative. Les traitements haut niveaux, et éventuellement une abstraction de tes données, si la vue utilisateur (dans les fenetre) est différente de ce qui se passe dedans.
 
Enfin, un troisième contient la partie IHM, les différentes fenètres (ie views).
 
Chacun de ces package sera re-découpé avec un core package (qui contient les services generaux du package), et des packages plus spécialisés autour.
 

 
Maintenant, faudrai voir la taille de l'application pour la granularité du découpage.

Ouaaah ! Merci beaucoup.
 
C'est super sympa, cette réponse personnalisée.

Une bonne question a se poser c'est savoir ce qui sera reutilisable dans un autre projet...
et ca ca te fais des groupes de classes que tu n'imagine pas de ne pas utiliser ensembles, souvent c'est un package