Discussion :

[Pirokkk]

Bonjour à tous !

Débutant en java, et plongé dans la conception de mon premier programme, j'aimerais construire une arborescence propre.

Je cherche des explications sur l'organisation des packages, je ne trouve pas grand chose...

Pourriez-vous m'expliquer de quelle façon organiser ses classes dans des packages, avec des noms et des relations cohérentes entre les classes, et les packages ?

Exemple : un package affichage ? un package avec des classes indépendantes ??

Merci !

Pirokkk.

[ndp]

Salut,

Pourriez-vous m'expliquer de quelle façon organiser ses classes dans des packages, avec des noms et des relations cohérentes entre les classes, et les packages ?

Exemple : un package affichage ? un package avec des classes indépendantes

les packages peuvent traduire le decoupage de ton appli en modules, donc ca depend de ton applis des choix de modules que tu fais.

exp:
Un module a une responsabilite plus large que celles assignees inidividuellement aux classes.
A l'interieur d'un package , je dirai pas de convention de nommage, garde des noms explicites pour tes classes, elle doivent avoir la meme responsabilite generale (forte cohesion).
Ce critere, tendra a eliminer les packages avec trop peu de classes. Il faut aussi veiller a ce que ton package soit compacte ie quelques classes publique, le reste masque.

[dinobogan]

Salut,

Il y a aussi la grande règle : "une classe d'un package ne peut faire référence qu'aux classes de son package ou d'un package fils."

Bien sur, ce n'est pas toujours facile, et dans certains cas impossible. Mais ça aide à la conception, et ça a l'avantage de s'obliger à bien découper les différentes parties à concevoir avant de se lancer dans le code.

[ndp]

Salut,

Il y a aussi la grande règle : "une classe d'un package ne peut faire référence qu'aux classes de son package ou d'un package fils."

Bien sur, ce n'est pas toujours facile, et dans certains cas impossible. Mais ça aide à la conception, et ça a l'avantage de s'obliger à bien découper les différentes parties à concevoir avant de se lancer dans le code.

C'est la premiere fois que j'entend cette "regle", je ne suis pas sur qu'elle aide vraiment,perso, je ne la suivrais pas. On dirait vaguement la notion d'architecture en couche...
Peut-tu preciser?

[Pirokkk]

Justement c'est cette histoire de référence et de lien qui me perds entre mes packages.
J'essaye d'avoir quelque chose de construit, avec des classes liées par un package (beaucoup de références entre elles)...et un peu plus tard je me rend compte qu'une autre classe d'un autre package vient chercher une ou deux classes de mon package....
Du coup je ne sais plus comment organiser cela !

Sinon, peux-t-on avoir des packages, et des classes seules à côté ?
Eh oui, si des classes n'ont pas lieux d'être dans un package déjà créés, et qu'elles sont indépendantes les unes des autres, comment faire pour garder cette organisation des packages, mais ne pas en créer un "poubelle" ou l'on met tout le reste, tout ce qu'on a pas pu caser dans les packages existants ?

Pour l'instant j'ai un package nommé "independant"...c'est moche hein !!

[ndp]

Justement c'est cette histoire de référence et de lien qui me perds entre mes packages.
J'essaye d'avoir quelque chose de construit, avec des classes liées par un package (beaucoup de références entre elles)...

Il faut que tu puisses etablir la responsabilite de ton package. Si tu y arrives, tu as un modules qui est plutot bien definie. D'un point vue interne au module, toutes tes classes ont la meme responsabilite (forte cohesion du module).
D'un point vue externe, tu t'enleves de la complexite, parce que peux prendre ce module comme un tout coherent, ie tu peux faire abstraction du detail.

et un peu plus tard je me rend compte qu'une autre classe d'un autre package vient chercher une ou deux classes de mon package....
Du coup je ne sais plus comment organiser cela !

mais ca c'est normal, si tu veux tes modules ne sont pas completement decouple, il faut bien faire interargir tes classes pour faire tourner ton application.
Mais il faut surveiller ces liens, si tu as pleins de classes qui interargissent avec toutes les classes de ton package, ca peut etre un signe d'un probleme dans ton design.

Sinon, peux-t-on avoir des packages, et des classes seules à côté ?
Eh oui, si des classes n'ont pas lieux d'être dans un package déjà créés, et qu'elles sont indépendantes les unes des autres, comment faire pour garder cette organisation des packages, mais ne pas en créer un "poubelle" ou l'on met tout le reste, tout ce qu'on a pas pu caser dans les packages existants ?

Pour l'instant j'ai un package nommé "independant"...c'est moche hein !!

je te propose "util" ou "common" c'est mieux !

[bassim]

généralement un package contient les classes qui sont fortement liées entre elles, du fait des règles métiers y régissantes et d'une certaine cohérence entre elles.

Ensuite 2 packages différents peuvent avoir des liaisons entre eux, mais il faut essayer de réduire leur nombre le plus possible pour garder une certaine indépendance (implique par la suite une maintenance plus facile et moins sujette à des erreurs).

[Patriarch24]

Il y a aussi la grande règle : "une classe d'un package ne peut faire référence qu'aux classes de son package ou d'un package fils."

J'aimerais bien savoir comment c'est possible...
Exemple : un package toto fait appel à la classe java.util.Date ; pourtant, il n'est pas le père de java.util, ni le même package...

Mais ça aide à la conception, et ça a l'avantage de s'obliger à bien découper les différentes parties à concevoir avant de se lancer dans le code.

Une architecture reste rarement figée dans le temps. Souvent, un module trop gros sera découpé, alors qu'un module trop petit sera absorbé par un autre.

[ndp]

...
Il y a aussi la grande règle : "une classe d'un package ne peut faire référence qu'aux classes de son package ou d'un package fils."
...

je pense qu'il y a confusion avec une architecture en couche : "une element d'une couche n'est conscient que des elements de sa couche ou d'une couche inferieure"

[dinobogan]

J'aimerais bien savoir comment c'est possible...
Exemple : un package toto fait appel à la classe java.util.Date ; pourtant, il n'est pas le père de java.util, ni le même package...

Une architecture reste rarement figée dans le temps. Souvent, un module trop gros sera découpé, alors qu'un module trop petit sera absorbé par un autre.

java.util.Date est justement un exemple à part. C'est le fameux package "independant" de Pirokkk cité plus haut.
Cette règle n'est pas à utiliser sur la vue projet, mais pour chaque API différentes importées dans le projet.
Mais elle date de très longtemps : peu après la sortie de Java. J'ai surement parlé un peu vite en ramenant ma science sans m'expliquer plus clairement