Discussion :

[ZeNoob]

Bonsoir,

Je me demandais à quel point les pojo sont utilisés en Java ?
Pour ma part j'en utilise tout le temps, dès que j'ai un argument de fonction que je souhaite modifier je crée un pojo pour cela.
Au final j'ai des pojo pour à peu près tous les types d'objets :
les entiers, les doubles, les vecteurs, les matrices mais aussi :
les couples d'entiers, les couples de vecteurs etc ....

Parfois ça me paraît un peu lourd alors je me demandais comment font les pros ?
Des pojos pour tous les types ou bien y a-t-il d'autres méthodes ?

____

Une autre question est niveau "bonne méthode de programmation" :
si je veux qu'une fonction renvoie plusieurs éléments, disons un double, un vecteur et un booléen, est-ce que je dois créer un pojo
triplet avec ces 3 types ou bien est-ce que je renvoie seulement un booléen et je passe les 2 autres en arguments via des pojos que je peux ensuite modifier ?


____

Et enfin dernière question :
J'ai 2 workspaces, l'un avec tous mes trucs de maths et l'un avec d'autres bricoles.
Mais évidemment maintenant j'ai besoin de mes outils de maths pour mes bricoles, alors comment faire pour utiliser mes lib de maths dans l'autre workspace ?
J'ai essayé d'ouvrir mon projet de maths dans mon workspace bricoles mais ça ne veut pas.

Peut-être que je ne dois avoir qu'un seul et même workspace pour tout mes travaux ?

Voilà, merci, à bientôt.

EDIT. ah oui j'oubliais je sur Eclipse Kepler

[thelvin]

Hello,

Oui non, tous ces trucs-là on peut pas vraiment dire que ce soit des POJOs. Enfin, au bout d'un moment chacun sa définition, mais ce qui est important c'est :

Un POJO ne désigne pas spécialement un moyen agaçant de contourner l'absence d'un mécanisme du langage (comme modifier un paramètre ou renvoyer plusieurs valeurs.) Un POJO n'est pas spécialement quelque chose dont on souhaite qu'il n'y avait pas besoin de le faire.

Un POJO représente une chose précise, et qui est composée de plusieurs données. Un POJO est une Personne, un Livre, un Article, un Voyage ou n'importe quoi qui est composé de données.
Bref il y a autre chose que des pis-aller dans les POJOs. Et les pis-aller, il vaut mieux s'en débarrasser, alors que la plupart des POJOs sont très bien.

Je me demandais à quel point les pojo sont utilisés en Java ?

Pas mal, je dirais. Chaque fois qu'on essaie de représenter une idée cohérente en mémoire. Je me répète : Personne, Livre, Article, Voyage, tout ça sont des bons candidats à être des POJOs.

Parfois ça me paraît un peu lourd alors je me demandais comment font les pros ?

Autrement.
Il n'est pas nécessaire de pouvoir changer un paramètre, on peut s'arranger différemment.

Par exemple on peut déporter la méthode vers un nouvel objet, qui contient un état interne. Cet état interne pourrait être ce qui était le paramètre avant.
Puis l'appel de la méthode modifie cet état interne (au lieu d'être un paramètre à modifier, donc,) et il est possible de demander à cet objet quel est le nouvel état.

Ce n'est qu'une des manières de faire, il en existe d'autres, la plus adaptée dépend de la situation précise. Ça demande un peu d'habitude, mais il n'y a pas vraiment besoin de changer les paramètres.

Une autre question est niveau "bonne méthode de programmation" :
si je veux qu'une fonction renvoie plusieurs éléments, disons un double, un vecteur et un booléen, est-ce que je dois créer un pojo

Souvent, oui. Mais il faudrait un nom plus sympa que Triplet.
Si tu renvoies tous ces éléments ensembles, la plupart du temps ce n'est pas un hasard. Ils forment un tout, et ce tout est une idée précise. Un Contrat, une Mesure, une Personne, un Camembert, peu importe mais quelque chose de précis.

Dans le cas où ce que tu cherches à renvoyer n'est pas vraiment un concept précis et utilisable ailleurs (c'est une bonne manière de décider : est-ce que ça aurait le même sens si on s'en sert ailleurs,) il vaut mieux s'organiser autrement que de créer encore une classe agaçante.
L'idée précédente, marche à nouveau : déporter le résultat de retour dans l'état interne de l'objet dont on appelle une méthode, et récupérer cet état interne avec des getters.
Ou alors définir une classe "Contexte" qui réunit toutes les données intéressantes du calcul en cours, et simplement modifier l'objet Contexte au lieu de renvoyer des données.
Ou encore autre chose...

Peut-être que je ne dois avoir qu'un seul et même workspace pour tout mes travaux ?

C'est mieux, oui. Sinon les deux workspaces vont se marcher dessus.

[ZeNoob]

Merci pour votre réponse,

Bon alors j'ai réorganisé mes projets en un seul workspace ça c'est fait.
Pour ce qui est des pojos j'ai, comme vous dites, utilisé des pojos à tout va pour contourner des problèmes que je ne sais résoudre (sans pointeur ou référence) mais j'ai réfléchi dessus et je ne vois toujours pas si j'emploie bien mes pojos ou non.

Bon alors pour être concrêt voici un exemple

J'ai une fonction qui prend en argument un objet et doit me rendre 2 objets de même type (type 'maClass' qui est finalement un genre de pojo).

Ce que j'avais fait c'est de créer une fonction :

Code :

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

public static boolean maFonction( maClass A, maClass R, maClass S) { /* ... */ return true; }

qui renvoie un booléen d'état (true si j'ai bien fait mon calcul, false sinon) et je renvoie mes 2 objets résultats R et S sans changer A.

Autre méthode que j'avais fait c'est de juste de ne pas la mettre en statique :

Code :

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

public boolean maFonction( maClass R, maClass S) { /* ... */ return true; }

et donc je n'ai en argument que mes objets de résultats.


Alors sinon voilà ce que j'ai fait ensuite :

je crée (encore) un pojo contenant 2 objets de type 'maClass' (donc un pojo contenant d'autres pojo, c'est sûrement pas très propre tout ça !) et je renvoie un booléen :

Code :

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

public boolean maFonction( monTypeGrosPojoAvecMesDeuxPetitsPojoDedans pojo ) { /* ... */ return true; }

je renvoie donc l'état de mon calcul dans le booléen et le résultat complet dans le pojo passé en argument.

pareil je peux la mettre en statique avec mon objet de base passé en argument :

Code :

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

public static boolean maFonction( maClass A, monTypeGrosPojoAvecMesDeuxPetitsPojoDedans pojo ) { /* ... */ return true; }

bon là ok j'aurais pu faire renvoyer le gros pojo par ma fonction et null si je ne peux pas calculer, mais si j'ai besoin d'un état de succès/échec un peu plus complet qu'un simple booléen j'aurais besoin de quelque chose genre :

Code :

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

public int static maFonction( maClass A, monGrosPojoAvecMesDeuxPetitsPojo pojo ) { /* ... */ return 0; }

où l'entier renvoyé indique quel genre d'erreur j'ai rencontrée.

Et enfin le dernier truc que j'ai fait c'est de créer un SUPER Pojo qui contient tout :
Mes 2 objets de type 'maClass' servant de résultat
et un booléen d'état de succès/échec dans mon calcul.

Code :

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

public static monSuperPojo maFonction( maClass A ) { /* .... */ return truc; }

Et évidemment je peux aussi faire ces deux dernières fonctions en non-statique.

Voilà rien que sur ce simple exemple j'ai plein de façon de faire
Alors quelle est la bonne, la mauvaise ? Je sens que vous allez me dire que tout dépend du sens de mes objets.
_____________________________

Et sinon je ne comprends pas bien ce que vous voulez dire par : "déporter la méthode vers un autre objet contenant un état interne".

Est-ce que vous voulez dire que dans mon type "maClass" je dois ajouter un membre 'flag' qui indique si oui ou non j'ai pu effectuer mon calcul ?
Ok ça je l'ai souvent fait dans d'autres contextes mais pour ce qui est de renvoyer les 2 objets, je ne sais pas trop ....

Voilà merci.

[thelvin]

Alors, on va commencer par un petit cours de français, que veut dire le mot : concret.

Eh bien concret veut dire, essentiellement, que rien de ce que tu n'as écris dans toute cette dissertation, n'est concret.
Pourquoi, eh bien parce que les méthodes s'appellent maMethode()* au lieu d'avoir un vrai nom. Les types s'appellent maClass au lieu d'être des vrais types. Il y a /*...*/ au lieu d'avoir du code. Il n'y a pas d'exemple qui se servent de ces méthodes en les appelant. Et enfin rien ne nous explique pourquoi tout cela a été fait au lieu de ne rien faire ce qui aurait été plus simple et plus efficace (autrement dit : à quoi c'est censé servir.)

Concret veut dire, que lorsqu'on observe quelque chose comme ça, cette chose n'est pas concrète.

* Parce que oui, aussi, ça s'appelle des méthodes, pas des fonctions. En gros, si c'est dans une classe, c'est une méthode. En Java il ne peut donc pas y avoir de fonction.

[ZeNoob]

Merci de votre réponse et désolé pour les imprécisions, je ne suis pas du tout dans l'informatique vous savez ^^

Bye bye
à bientôt.