Discussion :

[walfrat]

Effectivement, et c'est regrettable, les architecture en couche sont ne sont pas optimale en terme de déploiement, d'extensibilité horizontale, de performance et d'agilité.
Mais elle sont les plus simples à mettre en oeuvre, sont facilement testables, c'est pourquoi ce sont celle qu'on retrouvera le plus souvent.
Elle ont tout leur intéret sur des application simples de type CRUD, mais dès que ça se complexifie, d'autres approches sont plus intéressantes.

Ah, enfin des parôles censés sur le sujet autres que "c'est un anti-pattern donc c'est mal".

Mes premières années de développements grossomodo ont été des applications de gestion de données pure et dure.
Et je me suis fait des noeuds au cerveau en essayant faire autre chose que du modèle anémique... sans succès, au sens ou ça donnait quelque chose de plus complexe, moins testable, et sans gain réel pour moi.
Ma petit conclusion personnelle est que cet anti-pattern est en fait parfaitement adapté à ce qui relève de la gestion de données pure et dure, en revanche dès qu'on sort de la gestion de données, c'est une autre histoire.


Je vais apporter mon grain de sel sur ton dernier point sur lequle je suis d'accord. Le problème c'est que quand je veux proposer des approches plus riches pour traiter des problèmes plus complexes et bien je rencontre une forte résistance en mode "les autres ils comprendront pas" Pour ceux qui imagine le niveau de complexité dont je parle et bien imaginer simplement que les commentaires ne suffisent pas pour comprendre l'image globale et qu'il faut quelque diagrammes UML et réunion pour parler de conception uniquement, ben c'est de trop. Et à cela, on préfère souvent niveler par le bas, ce qui est extrêmement frustrant.

Pour ceux qui imaginent que ce que je propose c'est de refaire un méga framework usine a gaz, c'est évidemment faux je fais au mieux pour proposer des abstractions nécessaires répondant à de besoins actuels voir à couvrir dans un futur proche (oui YAGNI mais je n'aime pas non plus l'idée d'avancer totalement à l'aveugle, pour moi il faut quand même un minimum d'anticipation quand tu sais ce qu'il va arriver). Mais c'est l'excuse qu'on me brandis dès que j'essaye de faire un peu trop réfléchir les gens.

[StringBuilder]

Bonjour,

Je suis un peu surpris par ce que je lis à propos des montées de version de Java.
Qu'est-ce qui se cache derrière ces montées de version ?

Faisant du C# depuis la version 1.0 je n'ai vu que deux changements de versions à proprement parler :
Version 1.0 vers 1.1 : Premières erreurs de jeunesse, le Framework a été remanié, ce qui obligeait à réécrire une grande partie du code.
1.1 vers 2.0 : Refonte complète du Framework, et de nouveau, obligé re réécrire une grande partie du code pour que ça compile.

Aussi, le code JIT ayant été refondu complètement à l'époque, obligé de mettre à jour le Framework côté applicatif pour que ça tourne encore.

Cependant, on parle bien de signature de fonctions du Framework, ou de changements de namespace : donc une "réécriture" se faisait à 99% à grand coups de chercher/remplacer.


Depuis, on est en version 8.0 du langage, le Framework en version 4.8 (ou 3 pour Core) et 100% du code écrit en version .NET 2.0 compile parfaitement (aux quelques méthodes et types devenus obsolètes près).

On peut parfaitement faire tourner une application .NET 2.0 en installant uniquement le Framework 4.8...
Bref, à ce jour, je n'ai jamais vu de problème pour monter en version le langage, ni côté compilation, ni côté exécution. Même mieux, la plupart du temps, on peut faire tourner une application "récente" avec un Framework antérieur (quand on était à la version 4 de C#, rien n'avait évolué au niveau du JIT depuis la version 2.0 par exemple).


D'où mon interrogation à propos de Java : qu'est-ce qui empêche une application écrite en version 8, 11 ou je ne sais combien, d'être recompilée avec un compilateur récent ? Ou d'exécuter une application compilée avec une ancienne version de tourner avec un JDK récent ?

Le langage est-il à ce point remanié à chaque fois ? Le code intermédiaire est-il à ce point différent d'une version à l'autre ? Comment Sun à l'époque, et Oracle aujourd'hui justifient-ils ces versions qui ne sont pas retro-compatibles ?

[deltree]

Bonjour,

Je suis un peu surpris par ce que je lis à propos des montées de version de Java.
Qu'est-ce qui se cache derrière ces montées de version ?

Question très intéressante, et un peu compliquée, il y a plusierus question derrière tout ça:
- Java a une compatibilité ascendante, comme pour dot.net, mais ça concerne surtout l'execution du bytecode, et les API standard non dépréciée. (on était en version 1.x pour les premières version et vu qu'il n'était pas vraiment question de changer ce 1., on a finit par le skipper mais on est toujours compatible ascendant)
- Beaucoup d'équipe projet on peur de monter de version, ou simplement la flemme.

Qu'est ce que peut rendre du code incompatible:
- La syntaxe
- Les API du langage

Au niveau de la syntaxe, il y a quelques versions qui ont créé un vraie rupture:
- java5 (nommé 1.5 à lépoque, introduction des generics)
- java7 (évolutions mineures)
- java 8 (les lambda - grosse évolution mais pas forcément incompatible java7)
- java 9 (les modules jigsaw - grosse évolution également - grosse incompatibilité)

Pour java 10 11 et 12 on a aussi des évolutions mineures du langage qui ne devraient pas poser de problèmes de compatibilité, en dehors du déplacement de JavaFX depuis le SDK vers des modules externes.
Quand à recompiler, en fait c'est inutile et il ne vaut mieux pas, c'est la syntaxe elle même qui est parfois devenue incompatible (introduction du keyword "enum" par exemple en java 5) alors que le bytecode peut fonctionner

Pour les API, c'est une autre histoire, les API dépréciée peuvent être supprimée à la version suivante si on ne fait pas attention. Mais les incompatibilité les plus "graves" sont celles qui utilisent des API internes, c'est une mauvaise pratique de le faire car d'une version à l'autre et sans prévis elle peuvent être supprimées. Le problème c'est que certains des grand framework java utilisent ces API, et donc créent une incompatibilité sur certaines montée de version. ça oblige donc à retester et éventuellement adapter à chaque version un peu grosse (8 et 9 en ce moment)

Mais finalement il y a aussi et surtout le blocage "psychologique" (la peur ou la flemme comme je disais) qui veut que les équipes rechignent à mettre à jour. la ou je travaille on est bloqué en java 7 mais on commence quand même à tester le passage en java 8 et pour l'instant ça ne pose pas forcément de problème.
Le passage en 11 LTS (donc > à 9 et modules jigsaw) peut être plus problématique, mais ne nécessitera en vrai que le paramétrage des modules, c'est plus la montée de version des framework adaptés à cette version qui pose problème, c'est juste un peu de temps à passer et à tester.