Discussion :

[bruno bdf]

bonjour à tous,
je ne sais pas si je suis au bon endroit pour poser ma question.

je débute en Java, j'ai lu pas mal de tutoriaux et je commence à appréhender le concept d'objet mais pas encore celui de l'utilisation.
Ma question est : comment concevoir une application Java ?
quelles sont les techniques pour définir les objets, ceux qui seront définis dans un fichier Java.
je n'ai rien trouvé sur ces techniques.

Je me suis fixé comme but, de développer une galerie d'images, certes un projet ambitieux, mais il faut viser haut parfois.

merci à ceux qui me répondront.

[dinobogan]

Il arrive un jour ou il faut se lancer. Apprendre à nager en lisant un livre n'est pas possible. Comment expliquer la sensation de flottement ? Il faut se jeter à l'eau
Chacun à sa propre vision des choses. Tu peux partir dans du théorique en lisant des tonnes de bouquin. Mais il faut commencer à coder. Du simple au départ. Ton idée de projet n'est pas mauvaise : commence à coder une fonctionnalité très simple. Par exemple un objet qui va ouvrir une fenêtre avec un titre. Puis augmente tout doucement les fonctionnalités.
Avec le temps tu vas voir les problèmes qui surgissent. Il y aura aussi des défauts de conceptions, tu seras obligé de faire des retours arrière. Tu vas ensuite t'apercevoir que réfléchir sur le papier fait gagner du temps. Mais au niveau ou tu en es, j'imagine que tu ne sais pas très bien quoi écrire sur ton papier.
Alors code !

[tchize_]

d'abord, choisir un nom de package de base pour ton application (exemple, org.moi.gallery)
ensuite, définir, sur papier les classe dont à priori tu airat besoin, ces informations, tu les obtiens en analysant ton problème à résoudre. Dans ta gallerie d'image, tu arau probablement des descripteur d'image, des personnes ayant accès et des droits d'accès (pour faire simple).
Ensuite, toujours sur papier, tu essaie de trouver quelle propriétés sont intéressante dans ces objets. T'obtiendra principalement des objet avec juste des propriétés à ce moment
Ensuite tu essaie de dégager les méthodes d'interaction que tu veux entre ces objets. Ca te permet d'esquisser les méthodes dont tas besoin sur chaque objet
Ensuite tu ouvre ton éditeur et tu met tout çà en musique.

[futurD]

Salut!
Pour structurer un programme java ou objet plus généralement, je te conseilles de te renseigner sur l'UML (permettant de modèliser et donc penser ton programme: outils décrivant comment fonctionnera le programme et comment sera sa structure), le modèle MVC (empechant que ce soit le fouilli dans ton programme: on sépare la partie Vue, Métier (process, calculs), Contrôleur(faisant le lien entre Vue et Métier)). Aussi, package bien ton programme de manière cohérente.
Voila

espèrant t'avoir renseigné

[bruno bdf]

merci de vos réponses
j'ai toujours programmé, depuis une vingtaine d'années mais en langage procédural, avec une analyse détaillée. mais là il est vrai que je ne vois pas du tout comment organiser tout ça.
en informatique de gestion, sur AS400 pour être précis, on défini un écran, l'utilisateur saisis des données et quand il valide, on contrôle ces données, rien de plus simple pour moi.
mais là face à java, je me sens aussi dépourvu qu'un petit poussin qui vient de naitre...

je pensais qu'il y avait des techniques de conception.

tchize_ tu me parles de package, ok ça j'ai compris le concept, mais pourquoi org.moi.gallery ? je n'ai pas trouvé d'explication pour cette hiérarchie, c'est à ce genre de questions que je cherche des réponses.

[tchize_]

gallery, parce que c'est le nom de ton programme. org.moi, parce que comme çà, tu peut mettre com.company, truc.machin.biduel, ce que tu veux. CA permet de te différencier de toutes les autres applications java. Quand tu fait du code pour une société, il est recommandé de commencer le package par le nom de domaine de la société, mais c'est juste une convention, pas obligé de la respecter.

[in]

je pensais qu'il y avait des techniques de conception.

Ben je dirais que la principale technique est de s'abstraire de l'implémentation en ne pensant tout d'abord qu'aux concepts mis en oeuvre dans le programme. Note bien que ce que je raconte n'engage que moi, mais ça peut t'aider à démarrer ...

Il faut donc dans un premier temps, définir d'une part les objets du système et de l'autre leurs relations. Après plus tu affines, plus tu peux "découper" tes grosses abstractions (objets quoi) en plus petites (ou disons créer des familles d'objets). Pas la peine de penser en terme de classe à ce niveau (une relation peut très bien être implémentée sous forme de classe).

Par exemple : afficher une gallerie photo, implique les concepts

• Photo
• Conteneur de photos
• Utilisateur

Avec les différentes relations genre, un utilisateur gère certaines photos ; une gallerie contient des photos, des photos peuvent appartenir à plusieurs galleries ...

en raffinant, tu peux peut être déduire que :

• une photo est une image (fichier) et des méta données
• une gallerie peut contenir des photos de différents formats
• un utilisateur gère ses propres photos (a des droits), appartient à un groupe d'utilisateur

Bref tout ça pour arriver à un ensemble d'abstractions (assez fines si possible) qui reliées ensemble représentent ton système.

Une bonne orientation est aussi de définir les choses qui changent de celles qui ne changent pas. Par exemple une gallerie pourrait pouvoir gérer d'autres objets que des photos ...

Ensuite bien sûr, il existe des "règles" de conception objet, style préférer la composition à l'héritage, encapsuler ce qui varie ...

Dans tous les cas, cherche une solution simple à ton problème. Pas la peine d'ajouter de la complexité inutilement. Ensuite, si tu voies que tu dupliques du code, que des traitements peuvent être simplifiés ... là tu modifies ta structure, généralement en ajoutant de nouvelles abstractions ...

[bruno bdf]

merci pour ces précieux conseils même s'ils restent encore abstraits pour le néophyte que je suis

je ne manquerais pas de revenir...

[Mascotte]

Bonjour,

Je me permets de continuer dans ce topic pour reprendre ton exemple.

en raffinant, tu peux peut être déduire que :

• une photo est une image (fichier) et des méta données
• une gallerie peut contenir des photos de différents formats
• un utilisateur gère ses propres photos (a des droits), appartient à un groupe d'utilisateur

Je comprends très bien qu'il y ait ces trois objets : photo, gallerie et utilisateur mais je me demandais si on devait/pouvait imaginer que format était lui aussi un objet avec pour propriété 13x15, 15x18 etc...

A-t-on bien compris si on crée un objet qui n'a pas d'action (à part les get et set) ? Fait-il parti du métier ?

Est-ce que ces objets avec ces objets doivent faire une "phrase" ? Je m'explique :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Gallerie.gèreUnGroupeDePhoto()

tient la route alors que l'action suivante n'est pas logique d'un point de vu de français :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Photo.donneSesFormats()

les photos ne donnent rien, c'est l'utilisateur qui veut le format de cette photo. Cela veut-il dire qu'on a mal compris ce qu'on fait ? Est-ce mieux si on fait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Utilisateur.ObtientFormat(photo)

Ou finalement est-ce que tout cela revient au même ?

[tchize_]

Quelque commentaire:

pour le format, oui, si t'as des données plsu simple qu'un int (exemple une paire de int liés entre eux), c'est bon d'en faire un objet. Ensuite, pour tes noms de méthode, oui il faut un verbe. Mais tu les choisis mal.

Photo.donneSesFormats()

devrait être

Photo.getFormats()

Tu dois te placer du point de vue de l'appelant

[Mascotte]

Aaahhhh d'accord ! Là, ça s'éclaircit je crois. Merci beaucoup.