Salut!
 
J'ai une question sans doute simple...
 
Je me demandais quelle était la différence entre une définition d'un attribut d'une classe dans le corps de celle ci (mais pas dans son constructeur ou dans une méthode/constructeur) et sa définition dans le constructeur. Par exemple, la différence entre :
 

 
et ça :
 

 
Quand est ce que se fait l'allocation mémoire, etc?
 
Merci pour votre aide
 
 

dans le premier cas, l'allocation est faite avant d'entrer dans le constructeur.

perso je préfère initialiser mes variables dans le constructeur, je trouve ca plus propre, mais très souvent les gens initialisent tout ce qu'ils peuvent à la déclaration ...

http://forum.hardware.fr/forum2.ph [...] =4#t595378

D'accord, très bien, merci!
 
Donc, dans tous les cas, l'allocation d'espace mémoire se fera lors de l'appel suivant :  
 

 
Merci (en particulier à nraynaud pour son lien)

Je ne saisis pas la phrase. Je ne sais pas de quel invariant tu parles.

Oui, je sais. J'ai pas appris ça à l'école. La notion d'invariant ne m'est pas familière.

 
ah ouais carrément!  
 
Un exemple vraiment basique histoire d'avoir un truc concret à te mettre sous la dent
http://www.cs.cornell.edu/Courses/ [...] uests.html
 
precondition, postcondition et invariant
 

et ca te gêne pas d'un point de vue conceptuel que les initialisation ne soient pas faites dans le constructeur ?

de toutes façon je connais aucun prof qui conaissait.
 
l'invariant de la classe, c'est une équation logique que toutes les instances de la classe doivent vérifier.
 
Typiquement, les variables d'instance ne doivent pas être nulles, les Strings qui représentent des noms ne doivent pas être de longueur nulle, les chaches divers et variés doivent être cohérents etc. ça peut concerner tout et n'importe quoi, y compris de problèmes de synchronisation.
 
L'invariant doit être respecté chaque fois que quelqu'un a la possibilité d'utiliser l'objet, ça veut dire que pendant l'exécution d'une méthode, this peut être dans un état instable (invariant faux) à condition de revenir dans un état stable avant la fin de la méthode. Typiquement, tu modifies un objet, puis tu effaces les caches donc entre les 2 actions, les caches sont en vrac, mais c'est pas grave personne ne peut le savoir.

non.

<grain de sable>
seulement si les méthodes nécessitant cet invariant sont synchronizées ou que le prog est en monothread sinon c'est dtc Si c'est pas le cas, le this doit être stable même pdt l'execution d'une méhode.
</grain de sable>

même si le constructeur va devoir réaffecter certaines de ces variables derrière ? (ce qui est quand même suovent le cas ...)

 
Je crois qu'il y a du boulot ici.

Dans ce cas si.
Mais c'est vraiment pour me casser les couilles que tu postes ?
 
Je donne des lignes directrices, maintenant, il existe toujours des cas où c'est exactement l'inverse qu'il faut faire sauf que c'est pas la généralité.
 
Perso, j'utilise cette méthode autant que possible, ce qui veut dire pas beaucoup (parceque franchement, si rien dépendait des arguments passés aux constructeurs, on ferait tout en statique), par contre, il me parait important de garder à l'esprit la volonté d'avoir ses invariants corrects aussi tôt que possible.

   
 
non c'était pour avoir ton avis ...
 
mais si c'est pour me faire accueillir comme ca je le ferrai plus  

Merci pour vos réponses. Me voilà moins bête.

En tout cas, je suis ok avec le concept d'invriant, histoire de garder une sorte d'intégrité dans une classe! Donc, au maximum, factoriser ce qui est factorisable (sachant que le constructeur par défaut n'est pas toujours appelé)
 
En tout cas, merci, je serai moins bête, et surtout, j'ai la réponse à ma question originale !

hehe, ça me dit qqchose cette question

De toute façon, si tu décompiles ta classe, tu te rendras compte que toutes les initialisations faites, au niveau source, hors du corps des constructeurs, sont déplacées, au niveau bytecode, au début de chacun des constructeurs de la classe.
 
Donc du point de vue flot de contrôle, les initialisations des champs non statiques sont toujours et intégralement faites dans les constructeurs.
 
Maintenant, à toi de faire attention à ne pas initialiser 2 fois le même attribut... (sachant aussi que l'initialisation par défaut à 0/false/null des attributs fait partie de la spécification du langage Java, donc inutile d'en rajouter une couche par derrière).