[Curiosité] Comment trier les classes dans les packages

Heu je me demandais, comme ça, vous organisez comment vos classes dans vos packages? Quels sont les critères de tri?

Est-ce que vous groupez les classes qui font le même genre de choses, par exemple des packages pleins de classes Swings, d'autres packages pour contenir les contrôleurs, etc.?

Ou alors vous groupez les classes qui doivent bosser ensemble?... Par exemple, dans un seul package, on peut retrouver un JPanel (vue), deux-trois listeners (contrôleurs) ainsi que la partie "modèle".

Merci pour vos avis/réactions.

Je me pose personnellement la question a chaque nouveau projet :) Ca depend beaucoup de la taille et de la complexite du projet. J'utilise souvent des packages thematiques (par exemple ui pour les composants, math pour des classes mathematiques, animation pour mes animations, model pour le modele de donnees, etc.). Quand un composant est "gros" (beaucoup de classes) je lui reserve un package a part dans ui. Swing fait un peu pareil avec le package table par exemple.

Personnelement par fonctionalité, ce qui permet de reutiliser certain packages dans d'autres projets... Mais cela implique que tu ecrives un code assez "généraliste".

Dans le cas ou tu travaille avec des couches (chaque couche ne voyant que celle du dessus et celle du dessous), comment tu fais pour faire plusieurs packages si tu regroupe les classes qui bossent ensemble? :lol:

C'est un interessant probleme mais avant d'y répondre (oups, délà fait... :oops: ), il faudrait mieux que je bosse les Design pattern.

perso, je groupe par module applicatif. Et comme la si bien dit TabrisLeFol, ca permet de réutiliser des packages plus tard.

Pour le problème soulevé par TabrisLeFol, les patterns peuvent aider. En effet, en masquant une couche par une facade simple (pattern facade) on peut plus facilement découper l'application. La réutilisation de package sera facilitée puisque seule la facade sera éventuellement à changer.

C'est bien ce que je disais : ca depend de ce que tu fais. Dans ce que j'ecris je n'ai que tres rarement a reutiliser un package complet, mais plutot des composants ou meme des classes. Que je reintegrent souvent dans les nouveaux projets a grands coups de refactoring :)

[Completement hors sujet]
8O
J'avais pas vu ni réalisé :
Gfx = Romain Guy, Swing Team member = Desktop Java 16 Décembre 2005, Paris
Je suis content d'avoir pu voir la conference grace a java.developpez.tv. :D
[/Completement hors sujet]

Comme je le disais il faut que je bosse les Design pattern.
On (vbrabant, en fait :lol: ) m'a conseillé "head first design pattern". Bon je ne l'ai pas encore acheté mais je pense le faire et travailler dessus. Auriez vous des remarques sur ce livre ? Des suggestions? (d'autres livres, source...)

Tu as toujours l'excellent mais assez indigeste Design Patterns du Gang of Four (le seul des 4 auteurs dont je me souviens du nom est Erich Gamma).

Perso, j'ai toujours groupé les classes en fonction de ce qu'elles faisaient. Très schématiquement, un package pour la vue, un pour el contrôleur et un pour le modèle.

Puis je me suis tout récemment posé la question de savoir s'il ne valait pas la peine d'essayer, sur un projet relativement peu important, de grouper en fait les classes qui doivent bosser ensemble.

Ainsi j'ai, dans un même package, un JPanel qui affiche une liste connections JDBC, deux-trois listeners qui réagissent à la sélection d'un élément de cette liste, et bien entendu le modèle (une List de connections).

Le premier constat est le suivant: y'a une pellée de méhodes qui sont passées de public à package (par défaut), donc une diminution substantielle des risques d'impacts si je dois refactorer. Rien ne m'empêche d'ajouter un contrôleur qui permettrait à un module externe d'utiliser uniquement la partie "métier" (modèle).

Je me demande de plus en plus si le package doit servir à séparer physiquement les couches, comme c'est souvent le cas...

Citation:

---

Envoyé par TabrisLeFol

On (vbrabant, en fait :lol: ) m'a conseillé "head first design pattern".

---

Celui qui est orné d'une jeune fille sexy avec des couettes? Si c'est ça, j'en ai lu un chapitre, il m'a semblé complètement hallucinant de pédagogie :hola:

(bah oui, je suis visuel et j'ai pas la mémoire des noms)

Personnellement je trouve que non. Je trouve le decoupage par fonctionnalite bien plus interessant. Sur certains projets les deux decoupages sont tres proches. Dans le truc sur lequel je bosse notre modele a son package car il s'agit d'un ensemble de beans partages par un client et un serveur, mais nos vues et controleurs sont melanges et on a le meme avantage que celui que tu as note : tres peu de classes et de methodes publiques.

Glob : Oui c'est celui la.

Glob Je dois avouer que je connaissais la couverture du livre avant que vbrabant me le conseille :oops: car en effet la couverture n'est pas dans la norme habituelle des livres d'informatiques. En général, s'il y a des photos soit ce sont celles des auteurs soit des animaux... (Oui, c'est O'Reilly.)

Bon je prends en note Design Patterns du Gang of Four mais pas pour tout de suite car si tu le trouve indigeste moi, avec mon niveau actuel en Java ...
:koi: :triste: :koi:
Je vais donc commencer par le début et on verra pour la suite après (Oui, ça parait logique .... )

Le bouquin que j'ai cite donne des exemples en C++ et en Smalltalk mais c'est la reference.

Citation:

---

Envoyé par TabrisLeFol

[Completement hors sujet]
8O
J'avais pas vu ni réalisé :
Gfx = Romain Guy, Swing Team member = Desktop Java 16 Décembre 2005, Paris
Je suis content d'avoir pu voir la conference grace a java.developpez.tv. :D
[/Completement hors sujet]

---

+1