Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
1017 connectés 

 


Dernière réponse
Sujet : [JAVA]
BENB 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

Votre réponse
Nom d'utilisateur    Pour poster, vous devez être inscrit sur ce forum .... si ce n'est pas le cas, cliquez ici !
Le ton de votre message                        
                       
Votre réponse


[b][i][u][strike][spoiler][fixed][cpp][url][email][img][*]   
 
   [quote]
 

Options

 
Vous avez perdu votre mot de passe ?


Vue Rapide de la discussion
BENB 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
Cherrytree :) :) :) Ouaaah ! Merci beaucoup. :) :) :)
 
C'est super sympa, cette réponse personnalisée.
kadreg

Citation :


Est-ce qu'un découpage par fenêtre est judicieux ?


 
Ce serais le pire découpage possible :D .
 
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.
 
http://kadreg.free.fr/perso/ModelisationPackage.gif  
 
Maintenant, faudrai voir la taille de l'application pour la granularité du découpage.

Cherrytree 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 ?
kadreg 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).
Roswell_ 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é?
kadreg

Roswell_ a écrit a écrit :

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.




 
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 :D

wouatouwouatou 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 :D
Roswell_ 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.
kadreg 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 ?
 
http://kadreg.free.fr/perso/packages.gif  
 
- 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 :
 
http://kadreg.free.fr/perso/classes.gif  
 
 
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.
Cherrytree 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 !
kadreg 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.
missilsam :??:
kadreg 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

Code :
  1. package coincoin;
  2. class toto {
  3. }


 
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]

nicotine

Cherrytree a écrit a écrit :

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.




 
.jar ?

petoulachi mais tu veux savoir quoi a propos des paquetages ? :crazy:
Cherrytree 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.
petoulachi 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)
zop Il me semble que le compilateur fournit un fichier '.class' par classe
Cherrytree 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 ?
El_gringo 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 !
Cherrytree 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 ?

Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR