Discussion :

[renépaul]

Bonjour,

Je travail sur un projet qui consiste en un outil dont le but est d'automatiser des mesures sur des images medicales qui sont pour l'instant réalisées à la main. l'outils doit dsiposer d'une Gui, j'utilise la librairie dcmtk pour l'accès aux image itk pour le traitement des images et Qt pour l'interface.

j'ai déjas pas mal avancé dans mon projet mais je ne suis pas satisfait de la manière dont je l'ai organisé, et je me tourne vers vous pour avoir quelque conseil. (je n'ai pas vraiment de competence en conception informatique et je suis un peu partit sans trop réfléchir au début j'ai l'impression ).

Pour l'instant comme il s'agit de mesures assez procédurière (les mêmes mesures sont réalisées toutes les semaines, seule les images changent) j'était parti sur un Wizard dans lequelle j'affichait mes mesures, l'utilisateur n'a plus cas les controler et les refaires si elles sont mauvaise à l'aide d'outil intégrer aux Wizard.

ça fonctionne mais ça donne quelque chose d'assez lourd, j'ai eu notalment du mal à séparer les différent aspects: chargement des données, traitement puis affichage. au final tout à un peu tendance à ce retrouver dans mon QWizard et ça devient un gros mic mac.

mon outil devenant de plus en plus compliquer j'envisage d'abandonner le Wizard pour refaire mon projet dans une QMainWindows.et donc je voudrais en profiter pour réorganiser le tous mais j'ai du mal à voir comment faire, en particulier je ne sais pas ou "mettre" toute la partie mesure/traitement des images. pour l'instant j'avais regrouper les mesures dans des fonction amies avec mon QWizard (pour avoir acces aux donnée en attribut et à certaine méthodes) que j'appelais depuis les pages de mon wizard. Je me rend bien compte que c'est pas une solution élégante du tout .

J'aimerais bien que mon projet suive une architecture MVC, je sais que c'est possible avec Qt, j'ai d'ailleur déjas fait un petit viewer qui se sert de Q**ItemModel et Q**View pour navguer parmi les différentes image, mais là je vois pas trop comment faire.

Bref je ne vous demande pas de tous faire à ma place mais si vous pouvez simplement me donner des conseils, où même juste un petit coup de pouce je suis preneure.

merci d'avance, bonne journée.
rp

[tasna]

Si je comprends bien, tu as tout mis toutes les fonctions dans un seul fichier ?

Question GUI je ne peux pas beaucoup aider à part sur les fonctions de l'API Windows.

Crée plusieurs fichiers sources. Je faisais un fichier par fonction.

Crée des noms de variables explicites mais pas trop longs.

Si tu peux éviter de jouer avec les pointeurs, fais-le.

Déclares tes variables seulement quand t'en as besoin et supprimes-les dès que tu n'en as plus besoin.

N'oublies pas de réserver dans tes chaînes de caractères un emplacement pour le caractère délimitant la fin de la chaîne.

Gère chaque cas d'erreur.

Indente bien le code.

Evite d'inclure trop d'appels de fonctions dans un appel de fonction du genre :

Code :

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

1
2
 
fonction1(321,fonction2(fonction3(sizeof(int)+strlen(var))));

Evites le transtypage.

Je ne vois pas trop ce que je pourrais conseiller de plus.
Ce sont des règles très importantes pour moi qui n'est que développeur amateur depuis 4-5 ans.

Et bonne chance...

[koala01]

Salut

En fait, le principe du MVC est tout simple et se résume à trois mots : délégation des responsabilités

L'idée est donc gérer trois "modules" séparés :

1. Le modèle : on y retrouve toute la couche "business" de l'application. Dans ton cas, ce serait les données relatives aux images et les traitement possibles / envisagés
2. La vue : c'est, pour simplifier, tout ce qui offre un support "visuel" à l'utilisateur : IHM, graphiques, ...
3. Le controleur : c'est la partie qui sert de passerelle entre les deux: il récupère les événements de l'IHM et vérifie que ce que l'utilisateur demande a du sens, envoie les instructions au modèle pour effectuer les changements et renvoie (éventuellement) les résultats obtenus du modèle vers l'IHM afin qu'ils puissent être affichés comme attendu

[renépaul]

Merci pour vos réponse,

j'y est pas mal réfléchit depuis que j'ai poster, je pense avoir bien saisie le principe du MVC, c'est ça mise en oeuvre qui reste encore un peu plus obscure pour moi. Le problème viens du fait que je n'ai pas encore assez l'habitude de penser en therme d'objet plutôt que de fonction; du coup j'ai tendance à me retrouver avec des classe qui ne represente pas vraiment des objets mais se contente juste de rassembler des fonctions ayant un rapport les une avec les autres. je commence a être plus familier du concept même si je trouve pas toujours évident de dire si ça vaut le coup de creer un objet pour faire une tâche patriculière ou si il vaut mieux faire une bête fonction.

exemple je veux lire une image vaut il mieux simplement creer une fonction pour le faire, ou est ce que ça vaut le coup de creer un objet "lecteur" d'image ?

bonne journé,
rp

[Bousk]

Bonjour,

dans le cas d'une image, voilà comment j'imagine ça:
- une classe Reader, pour lire le fichier image
- une classe Image, qui contiendra les informations de l'image pour le logiciel (taille, pixels)
- une classe ImageDrawer qui sait afficher une Image

De cette manière, tu peux
- avoir autant de reader que de format d'images que tu souhaites prendre en compte (ReaderPNG, ReaderBMP, ...)
- avoir un Drawer différent pour différents cas (OpenGL, Qt, DirectX, ...)

Après pour la mise en place, j'hésite toujours entre héritage et composition.
Actuellement j'ai mis en place ça via héritage (Image hérite de ImageDrawer qui m'intéresse, et c'est ImageDrawer qui stocke les informations pixels etc de l'image), mais à chaque fois que j'y réfléchis je me dis que ImageDrawer membre de Image c'est autant valable (mais qui doit conserver les informations sur les pixels, tailles etc ? Image, avec des getter, Drawer en friend (chiant dans le cas où y'a plusieurs Drawer), ou Drawer directement (et dans ce dernier cas, comment initialiser les composants de Drawer à partir de Image - il n'a pas connaissance de Reader) ?)

[koala01]

Merci pour vos réponse,

j'y est pas mal réfléchit depuis que j'ai poster, je pense avoir bien saisie le principe du MVC, c'est ça mise en oeuvre qui reste encore un peu plus obscure pour moi. Le problème viens du fait que je n'ai pas encore assez l'habitude de penser en therme d'objet plutôt que de fonction; du coup j'ai tendance à me retrouver avec des classe qui ne represente pas vraiment des objets mais se contente juste de rassembler des fonctions ayant un rapport les une avec les autres. je commence a être plus familier du concept même si je trouve pas toujours évident de dire si ça vaut le coup de creer un objet pour faire une tâche patriculière ou si il vaut mieux faire une bête fonction.

Pour faire simple :

En OO, on s'intéresse plus aux comportements que l'on attend des objets qu'aux données qui permettent d'obtenir ces comportements.

L'idée est de créer des objets qui auront une responsabilité unique et clairement définie.

Une responsabilité peut, parfaitement, se décliner en plusieurs fonction, selon la responsabilité envisagée

Le gros avantage apporté par la conception OO sur de simples fonctions est la possibilité de recourir à la substituabilité: Si tu spécialises un objet pour une situation donnée, tu peux le transmettre à toute fonction qui manipule la version "générique" de l'objet (en fait, la classe mère ), et cela continuera à fonctionner...

Il t'est impossible d'obtenir ce résultat en n'utilisant que le paradigme impératif, car tu te retrouves face à l'obligation de réécrire le code pour chaque type de donnée particulier, même s'ils sont particulièrement proches

exemple je veux lire une image vaut il mieux simplement creer une fonction pour le faire, ou est ce que ça vaut le coup de creer un objet "lecteur" d'image ?

bonne journé,
rp

Ben...

Tant qu'à faire de l'orienté objet, autant le faire jusqu'au bout

Ne serait-ce parce que tes besoins risquent d'évoluer!!!

Un simple exemple : tu peux avoir considéré, pour l'instant, la nécessité de lire un seul format d'image bien particuler, et, dans ce cas, on pourrait estimer qu'une simple fonction ferait l'affaire...

Mais tu te bloques alors en terme d'évolutivité : si, dans deux semaines, on vient te dire que "oui, en fait, on a réfléchi... faudrait aussi prendre tel autre type d'image en compte",tu devras refaire tout une série de choses pour prendre ce nouveau format en compte et, le pire de l'histoire, c'est qu'une grande partie de ces choses existe déjà pour le premier format pris en charge : il n'y aura très certainement que quelques points de variation

Bonjour,

dans le cas d'une image, voilà comment j'imagine ça:
- une classe Reader, pour lire le fichier image
- une classe Image, qui contiendra les informations de l'image pour le logiciel (taille, pixels)
- une classe ImageDrawer qui sait afficher une Image

De cette manière, tu peux
- avoir autant de reader que de format d'images que tu souhaites prendre en compte (ReaderPNG, ReaderBMP, ...)
- avoir un Drawer différent pour différents cas (OpenGL, Qt, DirectX, ...)

+1

Après pour la mise en place, j'hésite toujours entre héritage et composition.
Actuellement j'ai mis en place ça via héritage (Image hérite de ImageDrawer qui m'intéresse, et c'est ImageDrawer qui stocke les informations pixels etc de l'image), mais à chaque fois que j'y réfléchis je me dis que ImageDrawer membre de Image c'est autant valable (mais qui doit conserver les informations sur les pixels, tailles etc ? Image, avec des getter, Drawer en friend (chiant dans le cas où y'a plusieurs Drawer), ou Drawer directement (et dans ce dernier cas, comment initialiser les composants de Drawer à partir de Image - il n'a pas connaissance de Reader) ?)

Il n'y a pas d'héritage à avoir!!!

Une image n'a strictement aucun besoin de pouvoir s'afficher ou se charger elle-même et un chargeur d'image n'est absolument pas une image, pas plus que n'est une image le système destiné à l'afficher

Tu as, au final, trois classes de base bel et bien distinctes : ImageLoader, Image et ImageDrawer.

Image et ImageLoader vont, très certainement, évoluer de pair : pour chaque nouveau type d'image, tu as de grandes chances d'avoir un loader équivalent

Quant à ImageDrawer, c'est en réalité un visiteur sur image, qui va utiliser l'interface de Image (ou de ses dérivées) pour ses propres besoins