48 votes

Structure d'un projet Java expliquée aux débutants ?

Je viens d'un environnement .NET, je suis complètement novice en Java et j'essaie de me faire une idée de la structure des projets Java.

La structure typique de ma solution .NET contient des projets qui désignent des composants logiquement distincts, généralement nommés selon le format :

MyCompany.SomeApplication.ProjectName

Le nom du projet correspond généralement à l'espace de nom racine du projet. Il se peut que j'aille plus loin dans la décomposition de l'espace de noms s'il s'agit d'un grand projet, mais le plus souvent, je ne vois pas la nécessité d'aller plus loin dans l'espace de noms.

Maintenant, en Java, vous avez des applications composées de projets, et puis vous avez un nouveau niveau logique - le paquet. Qu'est-ce qu'un paquet ? Que doit-il contenir ? Comment créer des espaces de noms dans ce App.Project.Package structure ? Quelle est la place des JAR dans tout cela ? En gros, quelqu'un peut-il fournir une introduction pour les débutants à la structure des applications Java ?

Gracias.

Editar: Des réponses très intéressantes, merci les gars. Quelques questions de suivi alors :

  • Les fichiers .JAR contiennent-ils du code compilé ? Ou seulement des fichiers de code source compressé ?
  • Y a-t-il une bonne raison pour que les noms des paquets soient tous en minuscules ?
  • Les paquets peuvent-ils avoir des "dépendances circulaires" ? En d'autres termes, le paquet.A peut-il utiliser le paquet.B et vice versa ?
  • Quelqu'un peut-il montrer la syntaxe typique pour déclarer qu'une classe fait partie d'un paquetage et déclarer que vous souhaitez faire référence à un autre paquetage dans une classe (une déclaration using peut-être ?) ?

34voto

Carl Smotricz Points 36400

Projets "simples" J2SE

Comme l'a expliqué cletus, la structure du répertoire des sources est directement équivalente à la structure des paquets, et cela est essentiellement intégré à Java. Tout le reste est un peu moins clair.

Beaucoup de projets simples sont organisés à la main, ce qui permet aux gens de choisir une structure qui leur convient. Ce qui est souvent fait (et cela se reflète également dans la structure des projets dans Eclipse, un outil Java très dominant), c'est que l'arbre des sources commence dans un répertoire appelé src . Vos fichiers sources sans paquetage se trouveront directement dans src, et votre hiérarchie de paquetage, qui commence généralement par un fichier com serait également contenu dans le répertoire src . Si vous CD a la src avant de lancer l'application javac votre compilateur compilé .class se retrouveront dans la même structure de répertoire, chaque fichier .class se trouvant dans le même répertoire et à côté de son fichier .class. .java archivo.

Si vous avez beaucoup de fichiers sources et de classes, vous voudrez les séparer les uns des autres pour réduire le désordre. L'organisation manuelle et Eclipse place souvent un bin o classes parallèle à src de sorte que les fichiers .class se retrouvent dans une hiérarchie qui reflète celle de l'entreprise. src .

Si votre projet comporte un ensemble de .jar pour délivrer les capacités des bibliothèques tierces, puis un troisième répertoire, typiquement lib est placé parallèlement à src y bin . Tout dans lib doit être placé dans le classpath pour la compilation et l'exécution.

Enfin, il y a tout un tas de choses qui sont plus ou moins facultatives :

  • docs en doc
  • ressources en resources
  • données dans data
  • configuration en conf ...

Vous comprenez l'idée. Le compilateur ne se soucie pas de ces répertoires, ce sont juste des moyens pour vous de vous organiser (ou de vous embrouiller).

Projets J2EE

J2EE est à peu près l'équivalent d'ASP.NET, c'est un cadre massif (standard) pour organiser les applications Web. Bien que vous puissiez développer votre code pour les projets J2EE comme vous le souhaitez, il existe une norme ferme pour la structure qu'un conteneur Web attendra de votre application. Et cette structure a tendance à se refléter un peu dans la mise en page de la source également. Voici une page qui détaille les structures de projet pour les projets Java en général (elles ne correspondent pas vraiment à ce que j'ai écrit ci-dessus) et pour les projets J2EE en particulier :

http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

Projets Maven

Maven est un outil de construction de projet très polyvalent. Personnellement, mes besoins en matière de construction sont bien couverts par ant ce qui correspond à peu près à nmake . Maven, quant à lui, est une gestion de construction complète du cycle de vie avec une gestion des dépendances ajoutée. Les librairies et les sources de la plupart du code dans le monde Java sont librement disponibles sur le net, et maven, si on le lui demande gentiment, ira les chercher pour vous et ramènera tout ce dont votre projet a besoin sans que vous ayez besoin de le lui dire. Il gère également un petit dépôt pour vous.

L'inconvénient de cette créature très industrieuse est qu'elle est très fasciste en matière de structure de projet. Vous le faites à la manière de Maven ou pas du tout. En vous imposant sa norme, Maven parvient à rendre les projets du monde entier un peu plus similaires en termes de structure, plus faciles à gérer et plus faciles à construire automatiquement avec un minimum de données.

Si vous optez un jour pour Maven, vous pouvez cesser de vous soucier de la structure du projet, car il ne peut y en avoir qu'une seule. C'est celle-là : http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

13voto

dball917 Points 317

Un paquetage en Java est très similaire à un espace de nom en .Net. Le nom du paquetage crée essentiellement un chemin vers les classes qu'il contient. Ce chemin peut être considéré comme l'espace de nom de la classe (en termes de .Net) car il constitue l'identifiant unique de la classe spécifique que vous souhaitez utiliser. Par exemple, si vous avez un paquet nommé :

org.myapp.myProject

Et à l'intérieur, il y avait un tas de cours :

MyClass1
MyClass2

Pour se référer spécifiquement à ces classes, il faut utiliser :

org.myapp.myProject.MyClass1
org.myapp.myProject.MyClass2

La seule véritable différence entre Java et .Net (à ma connaissance) est que Java organise ses "espaces de noms" de manière structurelle (chaque paquetage est un dossier distinct), alors que .Net vous permet d'étendre les classes à l'aide de la balise namespace et ignore où se trouve réellement le document.

Un fichier JAR est à peu près analogue à une DLL dans la plupart des cas. Il s'agit d'un fichier compressé (vous pouvez les ouvrir avec 7zip) qui contient le code source d'autres projets qui peuvent être ajoutés comme dépendances dans votre application. Les bibliothèques sont généralement contenues dans les JAR.

Ce qu'il faut retenir de Java, c'est qu'il est très structurel ; l'endroit où se trouvent les fichiers est important. Bien sûr, l'histoire ne s'arrête pas là, mais je pense que cela devrait vous aider à démarrer.

7voto

cletus Points 276888

Un paquet ressemble beaucoup à un espace de noms .Net. La convention générale en Java est d'utiliser votre nom de domaine inversé comme préfixe de paquetage. Ainsi, si votre société est example.com, vos paquets seront probablement :

com.example.projectname.etc...

Il peut être décomposé en plusieurs niveaux plutôt qu'un seul (nom du projet), mais généralement un seul est suffisant.

Dans la structure de votre projet, les classes sont généralement divisées en zones logiques : contrôleurs, modèles, vues, etc. Cela dépend du type de projet.

Il existe deux systèmes de construction dominants en Java : Ant et Maven.

Ant est essentiellement un langage de script spécifique à un domaine et est assez flexible, mais vous finissez par écrire vous-même beaucoup de choses passe-partout (tâches de construction, déploiement, test, etc.). Mais c'est rapide et pratique.

Maven est plus moderne et plus complet et vaut la peine d'être utilisé (imho). Maven est différent de Ant en ce sens que Maven déclare que ce projet est un "projet d'application Web" (appelé un "projet d'application Web"). archétype ). Une fois que cela est déclaré, la structure du répertoire est imposée une fois que vous avez spécifié votre groupId (com.example) et artifactId (nom du projet).

Vous obtenez beaucoup de choses gratuitement de cette façon. Le véritable avantage de Maven est qu'il gère les dépendances de votre projet pour vous. Ainsi, avec un pom.xml (fichier de projet Maven) et un Maven correctement configuré, vous pouvez le donner à quelqu'un d'autre (avec votre code source) et il peut construire, déployer, tester et exécuter votre projet en téléchargeant automatiquement les bibliothèques.

Ant a quelque chose comme ça avec Ivy.

7voto

Jamie McCrindle Points 3347

Voici quelques notes sur les paquets Java qui devraient vous aider à démarrer :

La meilleure pratique pour les noms de paquets Java est d'utiliser le nom de domaine de l'organisation comme début du paquet, mais en sens inverse, par exemple si votre entreprise possède le domaine "bobswidgets.com", vous commencerez votre paquet par "com.bobswidgets".

Le niveau suivant sera souvent celui de l'application ou de la bibliothèque, donc s'il s'agit de vos bibliothèques de commerce électronique, cela pourrait être quelque chose comme "com.bobswidgets.ecommerce".

Plus bas, cela représente souvent l'architecture de votre application. Les classes et interfaces qui sont au cœur du projet résident dans la "racine", par exemple com.bobswidgets.ecommerce.InvalidRequestException.

L'utilisation de paquets pour subdiviser davantage la fonctionnalité est courante. En général, le modèle consiste à placer les interfaces et les exceptions dans la racine de la subdivision, quelle qu'elle soit, et l'implémentation dans des sous-paquets, par ex.

com.bobswidgets.ecommerce.payment.PaymentAuthoriser (interface)
com.bobswidgets.ecommerce.payment.PaymentException
com.bobswidgets.ecommerce.payment.paypal.PaypalPaymentAuthoriser (implementation)

Ainsi, il est assez facile d'intégrer les classes et les paquets de "paiement" dans leur propre projet.

Quelques autres notes :

Les paquets Java sont étroitement liés à la structure des répertoires. Ainsi, dans un projet, une classe dont le package est com.example.MyClass se trouvera invariablement dans com/example/MyClass.java. En effet, lorsqu'elle est empaquetée dans un Jar, le fichier de classe se trouvera certainement dans com/exemple/MyClass.class.

Les paquets Java sont faiblement couplés aux projets. Il n'est pas rare que les projets aient leur propre nom de paquetage distinct, par exemple com.bobswidgets.ecommerce pour le commerce électronique, com.bobswidgets.intranet pour le projet intranet.

Les fichiers Jar contiennent les fichiers de classe qui sont le résultat de la compilation de votre code .java en bytecodes. Il s'agit simplement de fichiers zip avec une extension .jar. La racine du fichier Jar est la racine de la hiérarchie de l'espace de nom, par exemple com.bobswidgets.ecommerce sera /com/bobswidgets/ecommerce/ dans le fichier Jar. Les fichiers Jar peuvent également contenir des ressources, par exemple des fichiers de propriété, etc.

4voto

Nathan Hughes Points 30377

Un paquetage est un regroupement de fichiers source qui leur permet de voir les méthodes et les variables privées des autres paquets, de sorte que ce groupe de classes peut accéder à des éléments de l'autre classe que les autres classes ne peuvent pas voir.

On s'attend à ce que toutes les classes Java aient un paquetage qui est utilisé pour les désambiguïser. Ainsi, si vous ouvrez un fichier jar dans votre projet, comme spring, chaque package commence par org.springframework. Les chargeurs de classes ne connaissent pas le nom du fichier jar, ils n'utilisent que le package.

Il existe une pratique courante consistant à décomposer les choses par type d'objet ou de fonction, mais tout le monde n'est pas d'accord sur ce point. Comme Cletus l'a indiqué ici, il y a une tendance à regrouper les contrôleurs Web, les objets de domaine, les services et les objets d'accès aux données dans leurs propres paquets. Je pense que certains adeptes de la conception pilotée par le domaine ne pensent pas que ce soit une bonne chose. L'avantage est que tout ce qui se trouve dans votre paquetage partage le même type de dépendances (les contrôleurs peuvent dépendre des services et des objets de domaine, les services dépendent des objets de domaine et des objets d'accès aux données, etc.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X