Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Cherche recommandations/normes d'écriture pour Java 1.6
Bonjour,
J'aimerais savoir si quelqu'un a connaissance de recommandation, préconisations dans le cadre de la programmation java en 1.6.
Je recherche un doc du type http://java.sun.com/docs/codeconv/CodeConventions.pdf un peu plus à jour, préconisant par exemple l'utilisation des boucles for améliorées, la pratique de l'autoboxing (ou pas), pour des raisons de perf, de lisibilité ou d'homogénéisation.
Merci.
______
À ma connaissance cela n'existe pas ; tout le monde suit 90% de ces recommandations ou essaie. Seulement 5% parvient à suivre la recommandation principale : Donne-toi n'importe quelles règles, mais suis-les.
Il me semble que la pratique s'oriente aujourd'hui vers l'usage d'outils style PMD, qui enregistre quantité de règles d'écriture, et font autant de warning quand au code qui ne les respectent pas. Ces outils rendent de grands services, et sont configurables à l'infini.
Et sur un cas particulier tu peux demander l'avis d'autres ici même.
Sun a en effet édicté des règles de bases mais tu peux largement les enrichir en fonction de contraintes propre à ton activité. Si tu cherches des exemples, divers projets open-source publient leur règles de codage (voir les site d'apache, d'eclipse...).
En parlant d'eclipse, si c'est l'IDE que tu utilises, il existe un bon plug-in qui permet d'intégrer la vérification des règles au développement à l'adresse http://eclipse-cs.sourceforge.net/. De nombreuses règles de base sont déjà configurées (plus complètes que celles de Sun si ma mémoire est bonne), la configuration est simple et il est possible d'écrire ses propres règles.
Tu peux aussi tenir compte des évolutions apportées par d'autres langages
http://codemonkeyism.com/generation-...ramming-style/
Très sympa ce site, de bonnes pratiques expliquées.Envoyé par verbose
Ah je suis bien content de voir que les attributs publics et final trouvent un intérêt !
Il y a quelques temps j'avais eu une discussion sur ce forum pour dire que je "sentais" que lorsque un attribut était final il valait mieux le mettre directement en public au lieu de faire un getter, on m'avait bien sûr fait remarquer que c'était pas prudent, voire pas normal, ou pire déconseillé, et je vois qu'une tendance est en train de se faire jour en ce sens, merci les américains !
Je fiche immédiatement ce site sur ma page netvibes.
codemonkeyism.com ? Crénondidiou, ce site me pique les yeux de par les mauvaises pratiques qu'il propose
Sinon, comme ça a été cité : CheckStyle, aussi dispo en plugin pour Eclipse et NetBeans (centres de mise à jour NetBeans pour CheckStyle 1 : http://www.sickboy.cz/checkstyle/aut...autoupdate.xml, et CheckStyle 2 : http://www.sickboy.cz/checkstyle/aut...toupdate-2.xml)
Une merveille.
Salut,
Je paries que tu as eu ce débat avec moi !
Perso je vois très peu d'intérêt à cela... si ce n'est de limiter l'évolution du code !
+1codemonkeyism.com ? Crénondidiou, ce site me pique les yeux de par les mauvaises pratiques qu'il propose
Je vois très peu d'intérêt dans tous cela, mis à part pour les remarques #1 concernant final et #5 sur les interfaces...
a++
Les attributs certes, mais l'article évoque tout un tas d'autres éléments importants qui peuvent être finalisés. Un code est clean, je pense, quand tous les éléments qui le composent ont la portée minimum qu'ils peuvent avoir. C'est vrai pour la portée au sens accessibilité (public, private, etc...) mais aussi pour la modifiabilité et l'extensibilté. Donc tout ce qui peut être final dans du Java devrait l'être, i.e.:Ah je suis bien content de voir que les attributs publics et final trouvent un intérêt !
- Les attributs des classes qui sont invariants,
- Les variables locales qui ne sont pas réaffectées,
- Pour les paramètres de méthodes, la question ne se pose pas, il devraient toujours l'être,
- Les classes qui ne sont pas dérivées (i.e. si on veut être aussi rigoureux que possible, toutes les classes qui ne sont pas abstraites ; si, si, c'est toujours possible),
- Toutes les méthodes qui ne sont pas "Overridées".
Et, comme par un effet du hasard, les IDE peuvent souvent rajouter les mots clef final pour nous partout où c'est possible.
Ça, ça dépend des cas à mon sens. masquer des attributs peut avoir une signification sémantique. Mais quoi qu'il en soit, utiliser un getter pour lire un attribut final est effectivement inutile et contre-productif.je "sentais" que lorsque un attribut était final il valait mieux le mettre directement en public au lieu de faire un getter
Pas tout à fait d'accord. Cet article propose quelques éléments méthodologiques tout à fait pertinents, à l'exclusion du point 2 qui est de nature à faire faire beaucoup trop d'opérations d'allocation inutiles. Le point 3 peut quand à lui être complété ; parcourir une liste en y appliquant un filtre, ça se fait en créant un itérateur sur celle-ci.codemonkeyism.com ? Crénondidiou, ce site me pique les yeux de par les mauvaises pratiques qu'il propose
Salut,
+1
Pas forcément, perso j'utilise parfois quelque chose du style :
Mais bon là je chipote
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
Là par contre je ne suis pas d'accord ! On casse toutes les possibilités d'évolutions pour rien
Cela permet de cacher l'implémentation.
a++
La tu pense programmation fonctionnelle et non programmation objet. C'est le principe même de l'encapsulation. T'as pas a savoir ce que fait l'instance qu'on te passe en interne ni comment elle le fait. Donc un getter est utile dans la pluspart des cas. Personellement, les seule cas ou je les outrepasse, ce sont les cas ou j'ai des garantie de controle total, par exemple quand l'attribut en question est sur une static inner class non visible de l'extérieur et que l'objet en question n'est qu'un support de donnée entre des appels de méthode.
Quand au mot clé final sur les méthodes, avec un telle pratique, bonne chance lorsque tu gèrera des projets avec de nombreux sous projet. Quand le projet X aura besoin de faire une sous classe de Y pour une raison quelconque et que pour ça faut modifier le projet Y mais que le projet Y il est géré par un autre équipe et que l'équipe en question peut pas te faire une release stable de la dernière version de Y avant dans 3 semaine et que ton projet X doit être fini dans 2 semaines.... Tu va finir avec un fork de Y spécialement pour ton projet avec juste un mot clé retiré... Et ce our chaque librairie ou le problème se rencontrera :s
Honnêtement, y a rien de plus pénible que de tomber sur une méthode final que t'as besoin d'écraser dans une librairie sur laquelle t'as pas le controle.
Je connais pas beaucoup de méthode final dans l'api de sun. Il y en a partout sur Vector. Combien de fois j'ai pas entendu des programmeur autour de moi raler parce qu'il ne pouvaient pas hériter de Vector ....
Bon, alors, ce qui n'était pour moi qu'une réflexion mise en pratique critique (les attributs publics finaux) devient brutalement une sorte de tout ou rien. Ainsi va l'informatique : des extrêmes, des chapelles. Tout placer en final sans autre forme de procès me semble ridicule.
Cet article, qui semble le proposer, propose aussi d'autres approches de la programmation (par objets immuables, par clones, etc). C'est cette autre approche qu'il faut comprendre et critiquer, pas le fait de mettre final à droite et à gauche.
Concernant les attributs final publiques, j'y voyais d'abord une plus grande élégance ; désolé, mais moi je trouve du plus total ridicule que 95% de mes getTruc se réduisent à un return truc, sous prétexte de ménager des évolutions inexistantes dans 95,95% des cas.
Parrallèlement, je me suis rendu compte que l'usage de final sur les attributs me guidait pour une initialisation plus claire de mes objets, et une plus grande clarté du code. Mais cela ne m'empêche pas de conserver des attributs non final, lorsqu'ils varient durant la vie du projet.
À partir de là, si pour les attibuts final l'usage est mieux ciblé, s'ils sont initialisés à un seul endroit parfaitement contrôlé (la non init d'un attribut final est une faute de syntaxe, donc visible dès la compilation), il me semblait jouable de parier sur le fait que cet attribut présentait une grande stabilité, par rapport au rôle propre de cet objet, et donc que l'on puisse se passer de get... et privilégier l'accés direct.
Et je rejoins totalement l'article sur ce point qui insiste sur la notion de rôle (mais en y adjoignant des interfaces, ce qui évidemment n'est pas pratique pour les attributs...)
De plus un attribut final, ne pouvant s'initialiser que par le biais du constructeur, un constructeur n'étant pas redéfinissable en java (il est forcément appelé par ses héritiers), est en quelque sorte transparent devant l'héritage : il est forcément maintenu.
Cela oblige aussi à considérer que, quelque soit ce que fait l'extérieur sur cet attribut, l'objet conteneur est capable de rendre un traitement correct. Mais que l'on fasse getTruc ou public truc cela revient au même, puisque de toutes manières truc se trouve libre à l'extérieur. L'avantage de la première forme étant qu'on peut contrôler et réagir un minimum à sa sortie, l'avantage de la seconde forme est que... on ne peut pas le faire : on est sûr que la lecture d'un attribut d'objet ne modifie pas cet objet, ce qui est une règle fondamentale de bonne programmation, sauf erreur.
Last but not the least, on réfléchit mieux sur les get et set, qui ne sont plus uniquement des garanties de bonnes programmation objet, mais donnent une indication sur les états d'un objet.
L'article donne un autre point de vue de la chose, en considérant qu'un objet doit être tout final, donc sans état, rejetant le marquage de ces états sur les traitements et les échanges, enfin je suppose. Peut être ?
+1Quand au mot clé final sur les méthodes, avec un telle pratique, bonne chance lorsque tu gèrera des projets avec de nombreux sous projet. Quand le projet X aura besoin de faire une sous classe de Y pour une raison quelconque et que pour ça faut modifier le projet Y mais que le projet Y il est géré par un autre équipe et que l'équipe en question peut pas te faire une release stable de la dernière version de Y avant dans 3 semaine et que ton projet X doit être fini dans 2 semaines.... Tu va finir avec un fork de Y spécialement pour ton projet avec juste un mot clé retiré... Et ce our chaque librairie ou le problème se rencontrera :s
J'ai eu un cas similaire avec une méthode private dans une librairie ... je suis passé par l'introspection pour modifier à chaud .... pas terrible
Il vaut mieux mettre les méthodes à protected (que private
Pour répondre à la question initiale, je conseillerait l'utilisation d'outil integrés à l'ide; les documents sont trop peu souvent lu par les équipes ....
Les objets immuables sont déjà très utilisé en Java. Mais l'article semble se concentrer uniquement sur ces derniers !
Donc on devrait bloquer toute possibilité d'évolution ?
Là je suis tout à fait d'accord : les attributs finaux permettent d'avoir quelque chose de très carré et bien propre ! C'est vraiment très intéressant à utiliser lorsque c'est possible.
Le problème avec cela c'est que tu montre au grand jour ta cuisine interne, et que tu t'interdis toute évolution.
Ce n'est pas parce que ton attribut est final, qu'il le restera pour toujours dans les évolutions de ta classe. Il y a de multiple raison qui font qu'un attribut peut évoluer sans que la propriété qu'il représente n'en fassent autant...
Et je ne parle pas du fait qu'il ne peut pas y avoir de surcharge d'attribut...
Oui : belle incohérence dans les propos !
Je ne comprend pas ce que tu veux dire par là ?
C'est le principe des objets immuables, déjà intégré dans Java (il n'y a rien de neuf là dedans). Ce qui me pose problème c'est que l'article semble présente cela comme la seule solution alors qu'on a également besoin de manipuler des objets muables...
Pour en revenir à l'article en question, le problème c'est qu'il se présente comme des généralités, mais cela s'applique pour la plupart des points à des cas très particulier...
- Final is your new love.
Je suis tout à fait d'accord en ce qui concerne les variables locales et les attributs lorsque c'est possible.
- No setters.
Là je ne suis pas d'accord du tout ! Cela implique qu'on ne devrait utiliser que des objets immuables !
Or si ces derniers sont très utiles (ils permettent de partager des objets sans effet de bord), ils ne s'appliquent pas à tous les cas !
Un exemple tout bête : sans "setter", tu serait obligé de totalement reconstruire ton interface graphique à chaque fois que tu veux modifier le moindre texte d'un label
Les notions de classes immuables et de classes muables doivent exister conjointement, car elles représentent deux utilisations différentes.
Enfin, je ne suis pas du tout d'accord concernant le fait de supprimer les "getters" pour les remplacer par des méthodes utilitaires. Cela limite forcément les cas d'utilisation...
- Do not use loops for list operations.
Oui et non...
Le problème c'est que cela repose sur des APIs qui ne sont pas standard...
Si on utilises ces librairies (ou qu'on se développe une méthode filter()) il n'y a aucun problème à cela, mais de là à en faire une norme il y a une marge...
Franchement la différence est assez minime :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
Code : Sélectionner tout - Visualiser dans une fenêtre à part List<Person> beerDrinkers = filter(persons, {Person p => p.getAge() > 16} );- [b]Use one liners:[/code]
Je ne suis pas trop fan du genre (mis à part pour la variable locale totalement inutile dans son exemple).
Perso entre :
et
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
Je prefère franchement utiliserla convention de Sun :
Code : Sélectionner tout - Visualiser dans une fenêtre à part public int add(int a, int b) { return a + b; }
Mais encore une fois c'est un cas ultra-particulier qui se limite aux méthodes d'une ligne...
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
- Use many, many objects with many interfaces.
C'est le second point sur lequel je suis d'accord.
L'utilisation des interfaces permet de rendre le code plus générique.
Mais il ne faut toutefois pas en abuser
- Use Erlang-Style Concurrency.
Je n'ai pas eu le temps de regarder cela de plus près... donc je ne me prononcerait pas là dessus.
- Use Fluent Interfaces.
Un petit oui car cela peut s'avérer pratique... mais avec l'absence d'un type "This" cela supporte mal l'héritage.
Enfin cela ne s'adapte pas forcément à tous les cas.
- Data Transfer Objects without setters and getters.
Déjà sont exemple est un peu biaisé, car d'un coté on a une classe muable, et de l'autre une classe "presque" immuable (il faudrait qu'elle soit final pour cela).
Mais surtout on perd tout l'interêt de la POO : plus d'encapsulation ni de surcharge possible !
a++
Avec les IDE moderne, sauf cas particulier de librairies dont l'analyse a été faite en prévision, il n'est souvent pas nécessaire de prévoir déjà les interface dès le départ. Dans les exemples qu'il donne, j'ai tendance à dire que, dès qu'une deuxième classe se retrouve avec le même set de comportements, à ce moment il devient intéressant d'en extraire une interface. Mais il est inutile de faire ces interfaces avant d'avoir ces deux classes, sinon on tombe dans un travers facile à atteindre: l'over-engineering.[*]Use many, many objects with many interfaces.
C'est le second point sur lequel je suis d'accord.
L'utilisation des interfaces permet de rendre le code plus générique.
Mais il ne faut toutefois pas en abuser
Ne pas hésiter à utiliser le refactoring autant que nécessaire. Extraire une interface dans un IDE, et refaire tous les code qui utilise la classe pour qu'ils utilisent l'interface, ca met 30 secondes dans un IDE moderne.
Même sans IDE ce n'est pas beaucoup plus long
C'est pour cela que je disais qu'il ne fallait pas en abuser !
Par contre il est bien de penser aux interfaces standard lorsque cela s'applique, comme Iterable/Closeable/Readable/Appendable...
a++
Et ben, ça a fait couler de l'encre (électronique)!!! Mais je trouve aussi que le débat est intéressant. Je vais essayer de répondre à tout...
C'est une pratique assez courante mais que je ne retiens pas. Je ne suis pas favorable au fait d'utiliser la copie dans la stack d'un paramètre passé à une méthode pour servir de variable locale. Autant en déclarer une nouvelle (ça ne coute pas beaucoup plus cher, c'est même le moins que l'on puisse dire). Donc en ce qui me concerne, je recommande l'utilisation de critères de compilation le plus dur possible dans l'IDE et ce cas est réglé comme une erreur. Ceci dit, on est OK pour dire que dans ce cas précis, il s'agit un peu de chipoter.public void method(MyObject value) {
if (value == null) {
value = DEFAULT_VALUE;
}
// utilisation de "value" qui n'est jamais null
}
Là par contre je ne suis pas d'accord ! On casse toutes les possibilités d'évolutions pour rienLà il s'agit beaucoup moins de chipoter en l'occurrence et ce point est à mon avis très structurant. En l'occurrence comme j'ai justement la responsabilité des sous projets inscrits eux mêmes dans des hiérarchies ascendantes de projets qui regroupent au total des centaines de personnes sur les activités de développement (mettons 500 pour fixer les idées), et tout ça avec des critères de fiabilité très très (très) sévères, je pense largement pouvoir m'exprimer.Quand au mot clé final sur les méthodes, avec un telle pratique, bonne chance lorsque tu gèrera des projets avec de nombreux sous projet.
D'abord, on ne casse absolument pas les possibilités d'évolution. Ce qui ne peut être fait par dérivation peut toujours l'être par composition et délégation (méthode qui est d'ailleurs celle recommandée par les auteurs du GoF et qui a le gros avantage d'éviter les overrides avec oubli d'appel de la "super" méthode). Ensuite, lorsque on fournit une certaine bibliothèque, qui possède des API, pour peu que celles-ci aient été bien conçues (cas certes rarissime), elles doivent aussi avoir une méthode d'emploi bien déterminée. Le fait que tout le monde puisse tout dériver et faire des overrides sur tout et n'importe quoi est une très sérieuse source de problèmes ET de perte de temps. En effet, une personne qui développe ne perdra pas de temps à savoir quelle méthode il doit dériver pour générer tel ou tel comportement si la plupart de celles qui sont disponibles ne peuvent pas l'être.
Pour ce qui est du JDK, le fait que rien ne soit finalisé pose parfois des problème (revérifie bien tchize_ mais Vector n'est pas final et ne comporte pas de méthode final). Petit exemple: JComponent. Cette classe est effectivement basée sur le fait qu'on peut tout dériver pour surcharger tous les comportements (dessin du composant, des bordures, des enfants). Combien de fois j'ai dû régler des problèmes (pas dans mon équipe) de personnes qui ont surchargé paint() de manière brute et pas paintComponent(), si possible sans appeler super.paint() et qui n'arrivaient pas au résultat attendu (un petit cas parmi d'autres).
L'exemple du JDK pas la seule référence en matière de bibliothèque. Prenons par exemple SWT. Celle-ci interdit (en runtime, certes) la dérivation des classes des widgets. Tiens donc
Tout ça pour dire que, dans le cadre du pilotage de développement volumineux, il faut pouvoir organiser de la manière la plus précise possible le travail des gens, et l'organisation c'est:
- Du classement,
- Des contraintes.
D'ailleurs les (quelques une parmi beaucoup d'autres) contraintes que j'évoque ici, je ne les ai pas sorties su chapeau. Elles sont le résultat d'un consensus discuté par un collège d'experts et leur application a été notoirement profitable.
Ça te semble peut être ridicule mais il vaut mieux à mon sens maximiser les contraintes dans un premier temps et, au besoin, les lever après réflexion s'il s'avère que la conception initiale est insuffisante plutôt que de devoir rattraper des erreurs d'emploi aux interfaces entre différents équipes qui se sont propagées partout (ce qui est en général irrattrapable, en fait).Bon, alors, ce qui n'était pour moi qu'une réflexion mise en pratique critique (les attributs publics finaux) devient brutalement une sorte de tout ou rien. Ainsi va l'informatique : des extrêmes, des chapelles. Tout placer en final sans autre forme de procès me semble ridicule.
Oui tu as raison. Disons que j'ai volontairement appuyé un peu fort sur ce point pour dire que cela peut à mon sens avoir un intérêt de laisser dans certains cas des attributs "public". Mais en effet, c'est plutôt à réserver à des cas bien précis. Je note par exemple que la classe Point citée dans la page web à l'origine du débat est peu ou prou une image de celle du JDK/AWT et que ses attributs sont effectivement public (et même pas final d'ailleurs). On trouve des cas similaires partout dans le code d'eclipse et pas seulement dans les bibliothèques graphiques. En général, ce genre de chose est utilisé dans du code qui est par nature relativement invariant et où les performances sont assez cruciales.La tu pense programmation fonctionnelle et non programmation objet. C'est le principe même de l'encapsulation [...]
Je suis d'accord aussi sur la problématique de portée. Ces pratiques ont une nature plutôt "interne". Mais pour résumer, je dirais que je ne suis pas catégorique sur le fait de systématiquement masquer les attributs.
Bon aller, c'est tout pour l'instant...
Je comprend vraiment ton avis
Disons que j'aime bien cela non pas pour des raisons d'optimisations, mais simplement pour éviter de manipuler deux références vers le même objet...
Cela n'offre pas toujours les mêmes possibilités, en particulier dans le cas où les types ne sont pas compatible.
Attention je n'ai pas dit qu'aucune méthode devait être final. J'ai simplement dit que ce ne devait pas être le cas automatiquement.
Si une méthode ne doit pas être dérivé, elle doit bien sûr être final bien sûr !
Je suis tout à fait d'accord avec toi concernant l'exemple de JComponent.paint(). L'API standard se traine malheureusement un grand nombre d'erreur difficilement corrigeable sans casser la compatibilité...
a++
Oui, on peut en effet rencontrer ce genre de problèmes. Je pense quand même qu'on peut dans pratiquement tous les cas s'en affranchir, et en tous cas de manière certaine dans du code dont on a le contrôle. Les interfaces dont il était questions ailleurs seront d'ailleurs très profitables pour traiter ces cas.Cela n'offre pas toujours les mêmes possibilités, en particulier dans le cas où les types ne sont pas compatible.
Maintenant, dans le cas de code sur lequel on a pas la maîtrise, on peut faire face à des situations un peu plus délicates. Il est vrai que si tu veux passer à une méthode qui attend un Vector (par exemple) une instance qui possède des comportements légèrement différents d'un Vector standard, pas d'autres moyens que de dériver. Ceci dit:
- Le problème ne se poserait pas si la méthode en question attendait une List. Et en ce qui me concerne, je ne suis pas favorable à l'utilisation des classes de collection du JDK ailleurs que pour leur instanciation. Dans le code, il me semble nettement préférable d'utiliser les interfaces (Collection, List, Map, etc etc).
- Est-ce que tous les cas ne peuvent pas être traités par une conception adaptée ? J'ai (fortement) tendance à penser que oui.
AbsolumentAttention je n'ai pas dit qu'aucune méthode devait être final. J'ai simplement dit que ce ne devait pas être le cas automatiquement.
Si une méthode ne doit pas être dérivé, elle doit bien sûr être final bien sûr !
Les possibilités d'évolution ne sont nullement cassées avec des attributs finaux publics, et c'est une légende urbaine que de dire qu'avec des getters et des setters elles sont facilitées.
Encore pire, les possibilités d'évolution ne sont nullement facilités par la multiplication des interfaces, l'accumulation des configurations ou que sais-je encore.
Ce qui facilite l'évolution est de comprendre ce que l'on informatise, comment cette chose évolue, et comment l'écrire dans le langage que l'on utilise. Ce n'est pas le code seul qui évolue, c'est le couple chose + écriture.
Si l'on ne pense qu'à l'évolution du code, alors effectivement on multiplie les interfaces et les getters, et l'on voit apparaître ces horipilantes FactoryBuilderImplImpl communes aux bibliothèques XML.
Un attribut final public a comme signification, en gros :
- cet attribut se contrôle entièrement à la création de l'objet,
- vous pouvez toutefois utiliser librement cet attribut, l'objet se comportera de façon logique et compréhensible à toutes vos modifs sur cet attribut.
- en lui même il fait partie des constituants visibles de l'objet, non de son état (mais il peut y avoir des constituants de constituants qui marquent un état).
Par exemple, une roue de bagnole.
Il va de soi qu'une bagnole a des roues a sa construction, toutefois on peut lui retirer (c'est pas tout à fait final, je l'admets) ou modifier ses roues, et si vous voulez faire évoluer la bagnole vous devez aussi réfléchir à l'évolution des roues ce qui me parait parfaitement logique, mais cela n'en bloque pas les évolutions. C'est le contraire qui est illogique : prétendre faire évoluer les roues sans considérer une évolution de la bagnole est complètement illusoire.
Enfin, question état, que la bagnole roule ou pas, elle a des roues (cela ne manifeste pas un changement d'état), roues que l'on voit (c'est mieux), et toujours les mêmes ; par contre, si elle roule, alors les roues tournent. Un changement d'état de l'objet peut impliquer un changement d'état des constituants, mais pas forcément de la présence de ces constituants.
Répondre avec citation
Partager