voila j'ai une matrice
 
100001100
010000110
001000011
000101001
000011010
 
et je doit prendre certaine ligne et les additionner modulo 2
par exemple je doi prendre la ligne 2 3 et 5
 
ca me donne
 
010000110
001000011
000011010
---------
011011111
 
 
je cherche le moyenne de représenter ca ...

t'es lourd sérieux. tu fais ta classe Matrice avec un tableau à deux dimensions derrière ou tu t'en trouves une déjà toute faite

ben ouais, un double tableau ...
c'est quoi le problème que tu te poses ?

tu te fais une classe avec des vector comme ca c'est dimensionnable à souhait
 
ou alors jette un coup d'oeil du coté des hashtable si tu as besoin de manipuler rapidement des enormes quantités de données...

déjà, pas Vector ni HashTable, mais ArrayList et HashMap ...
 
ensuite, utiliser des objets dimmensionable ou des structure avec algo de hashage, faut vraiment en avoir besoin, hein ! C'est nettement moins performant et plus gourmand en mémoire qu'en bête tableau à 2 dimmensions dans la majorité des cas (hors matrice creuses ou joyeuseté dans ce genre ...)

Tu sais, le rapport de perfos Vector/ArrayList et Hashtable/HashMap est beaucoup moins justifié qu'avant. Autant en 1.2 c'était peut-être un souci, autant en 1.4 ça l'est carrément moins. Je sais pu où j'avais trouvé un comparatif entre les objets synchro et les non-synchro en 1.4 et franchement, niveau perfos ça se valait pratiquement (sauf grosses utilisations de porc, là je dis pas)
 
EDIT : j'ai retrouvé, en plus c'était une conf à JavaOne http://servlet.java.sun.com/javaon [...] s/1522.pdf

bha ouais, j'avais loupé cette conf là, elle était en même temps qu'une autre que j'avais jugé plus intéressante
 
MAis bon, je vois pas l'intérêt d'utiliser des objets synchronisés si y en a pas besoin ...

Dans une appli de base, effecivement,  chu d'accord avec toi. Mais dans du code industriel qui peut être réutilisé n'importe où ou n'importe comment, j'aurais tendance à privilégier du synchronized pour éviter d'éventuels problèmes de multi-threading

de toutes façon, de la sunchronisation qui n'est pas planifiée c'est voué à l'échec donc inutile de synchroniser inutilement, c'est donner de fausses illusions.

J'ai lu et c'est intéressant
 
mais bon, la synchronization a un coup, même si il est faible. Ca veut dire que quand on en a besoin, il ne faut pas hésiter à en mettre, mais que quand on en a pas besoin, c'est quand même dommage d'en mettre ...
 
Y a des tas de gens qui utilisent Vector et HashTable par habitude, dans des casôù il n'y a a vraiment pas besoin de synchro ... c'est quand même dommage

J'aime bien le dernier slide

Toutafé. C'est juste que j'ai découvert ce papelard y a pas très longtemps et qu'il fait sauter quelques légendes, donc c'est assez sympa

exactement !!!
 
Combien y en a qui utilise des Vector ou des ArrayList synchronisés en se disant "on sait jamais", et qui pense que ca suffit pour que leur class soit thread-safe ?
A côté de ca ils font des parcours de leur collection sans synchronization sans penser que ca flingue la synchronization de la collection ...
 
bref : ne pas se faire chier avec la synchro tant qu'il n'y en a pas besoin, et le jour où il y en a besoin, la faire correctement, completement et intelligement (pas besoin de foutre du synchronized partout !!).

j'avais pas vu
 

ouep
 
de toute façon, j'ai toujours detesté les mecs qui passaient par ce genre de bricolage pour gagner 3 millisecondes ...
C'est autant de temps perdu qui aurait pu être passé à mettr een place un design propre qui aurait surement fait gangner bien plus en perf !

Non. Pour faire du code totalement réutilisable, tu fais une classe non synchronisée, et tu indiques quelle factory utiliser pour la rendre synchronisée, genre Collections.synchronizedList() ou Collections.synchronizedMap(). Et au passage, tu peux aussi fournir une seconde factory qui rend ta collection read-only (genre Collections.unmodifiableList() ou Collections.unmodifiableMap())...
Normalement, le caractère synchronisé de la collection ne fait pas partie de l'algorithme qui code son fonctionnement.

c'est pas toujours si simple que ca ...

... mais parfois si

Toi, t'as pas vu la gueule du code qui circule dans ma boîte, alors

Ben non, mais je connais le code qui circule autour de moi...
 
Mais comme dit le proverbe "Charité bien ordonnée..." ; donc ce n'est pas parce que le code dans lequel tu dois plonger est crade, que tu dois toi-même programmer crade (même si faire coexister du code propre et du code crade nécessite parfois quelques compromis   ).
 
benou> Mon expérience m'a montré que les seuls véritables gros problèmes qu'on rencontrait en tant que programmeur face à ce type de design étaient d'ordre... psychologique ! Beaucoup de chefs croient que c'est inefficace, parce que quand on leur présente, ça fait "pur et dur" (d'autres disent "universitaire", ce qui à leurs yeux n'est pas beaucoup mieux...   ).
Mais il faut savoir ce qu'on veut : du code spaghettisant, ou du code dont la réutilisabilité est maximisée ?

Vi, m'enfin pour la synchro, je savais pas que l'utiliser dans une fonction "pour le cas où" pouvait se révéler totalement inutile comme le dit nraynaud. Je pensais que c'était une sûreté facile à mettre en place pour éviter les accès concurrents en multi-threads

moi ce que je dis c'est que ce design ne fonctionne pas toujours voir même rarement : c'est souvent au sein d'une classe que la généricitée doit être gérée alors que ta solution ne permet que de synchroniser son interface publique. C'est parfois sufisant (exemple des classes de java.util), mais souvent ca ne l'est pas ...

Tout dépend de quoi on parle. Comme tu le dis très bien toi-même, il y a d'une part la question de déclarer synchronisées ou non certaines méthodes d'une interface publique, et d'autre part la question, pour une implémentation donnée, de synchroniser certains des composants qu'elle manipule.
 
Ma réponse précédente ne portait évidemment que sur le premier cas. Et je persiste : quand on parle de définir des collections, ou de manière plus générale de composants relativement élémentaires, alors on ne devrait pas avoir trop besoin de spécifier une quelconque synchronisation dans leur interface (sauf bien sûr dans le cas de composants gérant le parallélisme, genre pools de threads, sémaphores, etc...).  
 
Mais évidemment, quand on écrit du logiciel, il y a toujours un moment où il faut agréger les composants de base et fabriquer un composant de plus haut niveau, qui lui devra gérer la synchronisation en manipulant ses sous-objets : c'est le deuxième cas.
 
Mais dans ce 2ème cas -- sauf cas rares -- le fait de synchroniser l'utilisation de certains composants internes de ta classe ne devrait pas avoir d'impact sur l'interface de cette classe. Parmi les cas rares, il y a typiquement la cas du singleton.
 
Cei dit, si je ne m'abuse, dans le topic, la question ne portait que sur le sujet de déclarer ou non synchronisées les méthodes de l'interface publique.

certes le topic a quelques peu devie, mais je reviens sur la representation de matrices:
 
sur la mailing list "The Java Specialists" (liens dans la FAQ et ci dessous) on trouve qu'il ne faut pas faire de tableau a deux dimensions ou plus, les tableaux etant des objets en java et necessitant relativement beaucoup de resources. Ainsi, pour une matrice de taille n,m il est recommande de faire un tableau a une dimension de taille n*m et de calculer l'index a la main (ca va, pas trop fatiguant ca) plutot que de faire un tableau de tableau
 
Le lien => The Java Specialists newsletter n'70

C'est pas fatigant, mais c'est délicat. Pour avoir écrit des classes templates TwoDArray et ThreeDArray en C++, je sais qu'il faut faire très attention en &écrivant les indices.
 
D'un autre côté, une fois que c'est bien encapsulé et bien testé, c'est que du bonheur !

   
 
int idx = line * columnNumber + column

La notion de ligne et de colonne est toute relative. Quand tu multiplie un vecteur par une matrice, par exemple, tu peux choisir d'écrire ton vecteur en ligne ou en colonne. C'est purement conventionnel, l'un et l'autre sont corrects. Le tout est de choisir l'une des 2 conventions, de s'y tenir, et d'avoir ensuite une écriture du code cohérente, c'est tout.

ah on me signale dans mon oreillette qu'en objet on peut faire cohabiter à moindre coût ces 2 représentations pour les matrices et pour des vecteurs de scalaires, la distinction n'a pas de sens.

merci je sais bien, c'était juste un exemple pour montrer que ca avait rien de complexe ...

Je n'ai pas dit que c'était complexe (ou compliqué), j'ai dit que c'était délicat. Il faut réfléchir un peu, c'est tout.
 
nraynaud> Top crédibilité !