Version imprimable
Bonjour à tous,
Je suis à la recherche d'un guide d'organisation des packages Java
Une fois les packages modèles, vues, controlleurs de créés, je me demande où placer mes classes dédiées au système d'information (classe Personne, classe Etablissement par exemple) ou encore s'il est adéquat de placer le .java de la classe d'une JFrame dans le package controlleurs...
Merci pour vos éventuelles réponses
les package tu les organise un peu comme tu le veut tout en essayant de ne pas donner des nom trop générique pour ne pas avoir de conflit avec d'autre package existant ni en gardant le package par defaut.
ensuite pour ce qui est de ta JFrame, elle se rapporte plus au contexte de ta vue, donc non pour moi elle n'a pas sa place avec tes contrôleur
selon ta question, tu essaye de faire propre pour réaliser un pattern MVC ?
donc dans ton modèle, tu met tout ce qui concerne le traitement des tes donnée,
dans tes contrôleurs, tout ce qui est gestion des événements (par exemple en cas de clic de bouton, mouvement de souris ...)
dans ta vue, tout ce qui est de ton IHM, tes frame, panel et autre composant
ensuite ton contrôleur se charge de faire le lien entre ta vue et ton modele
Tout d'abord merci pour ta réponse, je ferai un peu comme je veux donc ;-)
Pourtant dans ma JFrame il y a autant de gestion d'évènements que de construction de nouveaux composantsCitation:
Envoyé par deglingo592003
Je croyais que seuls les renderers et les editors étaient contenus dans les vues
Merci encore
le design pattern n'est pas ma tasse de thé mais voila ce que j'en est retiré
pour le MVC tu a ton contrôleur qui fera le lien entre ton IHM et tes traitement de données
mais la plus part du temps on retrouve un M-VC où ta vue et tes contrôleur sont réuni (ce qui facilite parfois le travail ^^)
Ensuite, chacun y va de ses habitude (j'ai vu de tout à ce niveau)
le mieux étant de bien séparer tes traitement de ton IHM et d'éviter de mélanger les deux, pour moi rien qu'en respectant ceci, cela permet une meilleur lecture du code.
D'un coter tu as les calcul, de l'autre la création des composants et leur écouteurs
certaine tête sur le forum ont de meilleurs connaissance que moi sur les differents pattern, reste plus qu'a esperer qu'il passe par ici ^^
Pour prendre un exemple simple
tu a un modèle qui permet d'additionner deux entier
tu a ton contrôleur qui permet d'accéder a la fonction additionner de ton modèle
ensuite dans ta vue tu a un bouton qui permet de faire une addition, ta vue ne va pas appeler directement la fonction de ton modèle mais va prévenir le contrôleur qui lui va permettre de transmettre l'information au modele et ensuite va prévenir ta/tes vues de la nouvelle notification
Je te remercie pour ton temps et ton explication
Hélas la vie du programmeur n'est pas faite de choses si simples :(
Je suis à la recherche d'une convention de packaging comme il existe une convention de nommage de code par Sun en Java
Merci encore :zoubi:
:fleche: Les packages peuvent être vus comme des espaces de nommage.
Le package te permet donc en quelque sorte de préfixer tes classes pour éviter le conflit avec des classes au même petit nom (getSimpleName()).
Le nom complet d'une classe (getName()) (nom du package + nom de la classe) devrait en théorie être unique !
C'est pour cela :
- qu'on déconseille leur non utilisation ou les packages du style "librairie" ou "util"
- qu'on recommande (par convention) d'utiliser l'url de l'entreprise (http://ibm.com par ex.) en partant du plus général au plus spécifique - le tld, puis le domaine et les sous domaines - (com.ibm dans l'ex.)
De la même manière que les sous domaines d'une url (dans http://www.ibm.com ou http://ftp.ibm.com, www et ftp sont des sous domaines) sont libres, tu décides ensuite comment organiser ton code.
Certains créent ensuite des sous niveaux
- sur une base technique (file, database, ...),
- sur des patterns (model, view, controller)
- sur des domaines fonctionnels (author, admin, ...)
Personnellement, tout le réutilisable, je le met dans une/des librairies :
et pour mes applications :Citation:
com.company.app
com.company.file
com.company.database
com.company.time
com.company.text
...
mais qu'on aurait pu faire :Citation:
com.company.appli1.controller
com.company.appli1.model
com.company.appli1.view
com.company.appli2.controller.admin
com.company.appli2.controller.author
com.company.appli2.model.admin
com.company.appli2.model.author
com.company.appli2.view.admin
com.company.appli2.view.author
Citation:
com.company.appli2.admin.controller
com.company.appli2.admin.model
com.company.appli2.admin.view
com.company.appli2.author.controller
com.company.appli2.author.model
com.company.appli2.author.view