Reprise du message précédent :

si tu laisses ton *data dans la nature, j'en conviens. Si tu l'encapsule correctement dans une classe, ben rajouter un computeCRC32 comme methode de cette classe, c'est pas vraiment plus lourd.

 
bah l'exemple la est plutot bon vu que j'utilise le CRC32 pour a peu pres tout ce qui a besoin d'etre identifié de maniere unique (allant de la chaine de caractere a une image), je me vois pas dupliquer cette fonction dans toutes les classes en ayant besoin

 
bah vi, ca me ressort un machin 32bits rapidement. J'utilise ca comme identifiant, ca me coute pas cher (et vu que generalement mes collections sont pas du genre a compter 80000 element g pas encore eu de soucis de collision)
 
y'a un pb ?

bah dans ce cas tu fais comme a dit kadreg, tu le ranges dans l'equivalent a System pour ton appli (ou alors tu le mets dans une classe de base, et les autres classes en héritent, ca depends du cas)

 
Disons que c'est typiquement le genre de choses qui va péter dans 5 ans en prod lorsque tu tomberas sur la première collision après des millions d'objets créés sans problèmes.
 

 
Bah c'est un bete "hashage" qu'il fait... (non ?)
 
Les collisions sont possibles et normales, mais c'est pour ca que lorsqu'on utilise le hashage, tester uniquement l'egalite des hashs n'est pas suffisant. (deux donnees egales ont le meme hash, mais deux donnees ayant le meme hash ne sont pas forcement egales)
 
La seule question est de savoir si 32bits suffisent, si son algo repartis bien les hashs et s'il verifie bien l'egalite.

 
Tu viens de reformuler ce que j'viens de dire, je peux qu'être d'accord !  

 
non c'est toi qui a reformulé mon post initial nuance

 
Mouais bof, je prefere une classe utilitaire qui lui permet d'obtenir un singleton d'une instance de classe offrant la methode crc32(), methode definie dans une interface. Ainsi tu chache l'implem, tu separe les responsabilites, et tu centralise le probleme...
 
Je renommerais crc32() par hash() pour ne pas indiquer dans l'api le detail d'implem, ce qui laisse la possibilite de remplacer l'implem sans le montrer aux utilisateurs.
 
Ca ca me semble plus objet qu'une bete duplication de code dans toutes les classes (quelle horreur)... question mise a jour c'est horrible.

 
Bof, j'trouve pas. Mais bref, pour les méthodes "static", c'est pas très objet, mais c'est quand même bien pratique. Moi j'suis d'accord avec benou pour dire qu'il faut pas bêtemetn resté cloitré dans le concept objet, quite a se faire 100 fois plus chier dans certains cas. On a droit a quelques écarts (surtout quand ça simplifie la lisibilité, améliore les perfs, ...).

donc, si on te suite bien Darklord, Java n'est pas 100% OO (voir par exemple java.lang.Math)

Ah nan mais ça c'est certain. J'veux dire, par essence, y a des opérateurs, des trucs comme ça, donc nonm c'est pas 100% OO
Demander l'avis de lorill sur le sujet

 
Ben non, Java n'est pas 100% OO de toute façon, même sans compter ça. Déja les types primitifs, c pas objet du tout !

 
Des opérateurs ça empêche pas d'être objet. Enfin, s'ils peuvent être surchargés!

 
Effectivement 100% Objet signifie que tout passe par envoi de messages a des objets (et non pas par "appel de methode" qui n'est resolument pas objet), donc operateurs, visibilite des variables, etc... K.O.
 
 

Maintenant, est-ce que le "tout objet" est réellement une fin en soi... je sais pas. J'en suis personnellement pas du tout convaincu.

de toute façon, j'ai l'impression qu'on ne peut à la fois avoir un design parfaitement objet, avec une abstraction forte, et de bonnes performances.
Qu'on le veuille ou non, l'un se fait au détriment de l'autre

à ce propos, y aurait un bouquin sur un langage 100% objet, que je vois à quoi ça ressemble

 
Au bureau, on a un soft qui a réussi l'exploit d'avoir un design pas objet, n'importe quoi comme abstraction et des performances pourrites

Je trouve que ça répond plutôt bien à la question que je me posais.
En effet dans le cas qui m'occupe, il y a bien un petit problème de conception (en fait un raccourci pratique).
 
Merci pour ce petit débat !
 
K.

 
absolument

 
voilà

 
Disons, qu'en POO (note le 1er O pour "orientatiee" et non pas PPO pour "pur" ) on essaie de simplifier la vie aux developpeurs, d'ou l'apparition d'operateurs, etc...
 
Question POO, Smalltalk est bien plus propre que Java.
 
Essaie de trouver des presentations, articles de Stephane Ducasse a ce sujet (il bosse sur le refactoring, les DP, etc... bref sur les architecture Objet).

ca c'est ecrit nulle part
(si je me trompe, url valable siouplait)
 

aucun rapport, cf ruby, www.ruby-lang.org :
- les operateurs sont des methodes comme les autres (donc des messages, ici)
- la visibilité : toutes les variables sont privées, on passe obligatoirement par accesseurs (mais y'a des raccourcis pour les accesseurs, donc ca y ressemble). On pourrait aussi considérer la visibilité comme un attribut de la variable (c'est le cas dans mon prototype de langage), donc aucun probleme.
 
bref, n'importe quoi

 
Tsss...
 
Un appel de methode est un abus de langage (celui que l'on parle) que l'on devrait banir. En objet tu envois des messages d'un objet a l'autre en utilisant une interface comprennant ces messages. C'est tout ce que je voulais dire (demande a des gens qui bossent dans la recherche objet quel est leur avis concernant les "appels de methode" ).
 
Si tu as une methode qui represente un operateur tu n'as plus vraiment d'operateur... tu envois un message indiquant par exemple que tu desire additionner deux objets. Le "+" peut etre alors uniquement un ajout au langage permettant d'eviter de faire explicitement ces envois de message (a+b est plus aise et plus intuitif a faire que a.plus(b))
 
Les variables devraient etre toujours invisibles de l'exterieur et ceci sans exception. Pouvoir leur donner une autre visibilite revient a casser l'encapsulation, ouvrir la voie a l'aliasing non controle, etc... L'acces et modification, pour etre controlee et etre objet devrait donc, comme tu l'indiques, passer par des getter / setters. La encore si tu ajoute des raccourcis langage ce ne sont que des moyens de faciliter l'utilisation et ca ne change rien a ce qui se passe.
 
Tu confonds POO (oriente objet) et ce que j'appellerais PPO (pur objet)... Dans un cas tu profite des notions objet dans l'autre tu vis dans un monde 100% objet ou "+", variables visibles etc ne peuvent exister. Et a ce que je sache la question etait de savoir ce qu'est un langage 100% objet non ?
 
Si tu pense que je racconte n'importe quoi tu es libre de le faire... Je te demande juste de mettre un peu d'eau dans ton vin et d'arreter avec tes " " un peu excessifs...
 
Ciao

ça existe des talibans de l'Objet ?

 
Oh My God

ok merci  

Et pourtant, il est loin d'être propre (au niveau des classes surtout).
 
Eiffel me semble l'un des moins crades.