il ne s'agit pas d'exhausitivité…Envoyé par pseudocode
mais de regarder des cas précis de résolution de patterns de problèmes récurrents qui surgissent habituellement dans des situations types…
… problèmes qui classiquement ne sont pas abordés dans les tutoriaux de la plupart des environnements parce qu'ils ont une facheuse tendance à mettre en évidence leurs sales côtés…
la syntaxe des langages est une problématique relativement secondaire, sauf à attirer l'attention sur d'éventuelles constructions sources fréquentes d'erreur qui peuvent asser outre la vérification syntaxique du compilateur (genre le = et le == du C… du temps où il n'y avait pas le warning adhoc…)
le nombre de classes/méthodes d'une librairie n'a d'intérêt à être relevé que si cela traduit une erreur dans l'abstraction du problème censé être représenté par la classe ou un manque par rapport aux fonctionnalités encapsulées (par exemple une classe SSL qui ne donnerait pas accès à toutes les fonctionnalités sous-jacentes de SSL…)
le nombre de lignes de code pour des exemples triviaux n'a pas beaucoup d'intérêt, mais passer de 130.000 lignes à 48.000 tout en ayant plus de fonctionnalités couvertes, est une situation digne de commentaires…
(non, je rassure tout le monde, si l'exemple est réel, il ne concerne ni Java ni .Net…)
et comparer le temps qu'a mis X à comprendre Chose et Y à comprendre Machin ? … sans commentaire…
il n'y a pas que le problème du choix, qui sera souvent guidé par des critères externes (expertise acquise, environnement du client, …) , il y a aussi l'évaluation des coûts, du temps nécessaire, et des "risques" : les points - parfois annexes, donc souvent sous-estimés - qui font perdre du temps…Envoyé par pseudocode
de nouveau cette manie de répondre avant de lire et de comprendre :Envoyé par pseudocode
d'abord je ne cherche pas de formule magique, ensuite "la classique situation de la liste d'objets" n'est qu'un contexte pour aborder des petits problèmes qui peuvent vite se transformer en casse-tête avec certains frameworks :
que l'utilisateur puisse ordonner les colonnes à sa guise, décider celles qu'il voit et que cette customisation soit sauvegardée automatiquement d'une cession à l'autre ...
imaginons que N colonnes représentant des états booléens, mais que pour chaque ligne ce groupe de N colonnes doit se comporter comme un groupe de bouton radio, donc quand l'utilisateur met à ON l'une des colonnes qui était à OFF, celle qui était ON doit passer à OFF…
l'application a besoin de lignes dont la hauteur est dynamique et différente
de ligne en ligne
l'application a besoin d'entête de colonnes dont le contenu est une image…
d'entêtes de colonnes sur plusieurs lignes…
etc.
et bien sûr je ne prends ce contexte de GUI et de liste d'objets qu'à titre d'exemples car tout le monde peut visualiser mentalement de quoi l'on parle…
mais on pourrait s'amuser de même dans d'autres domaines comme par exemple l'incorporation d'un outil de bug reporting automatique dans une application en beta test…
(on remarquera que jusqu'ici personne n'a encore posté pour aucun des petits exemples : "cela je vois comment le réaliser : il faut faire 1, 2, 3, …")
et certes je ne m'attends pas à voir surgir des réponses en noir et blanc à ce genre de comparaison, les situations justifiant un no go pour l'une ou l'autre technologie devant être l'exception (enfin… c'est à souhaiter pour les "combattants" …)
mais on pourrait espérer voir un peu plus clair dans les points forts et faibles, surtout ceux que le hype marketing de l'un et l'autre essaie de cacher…
On pourrait aussi aborder les questions relatives à la qualité de la documentation :
lorsqu'on pousse un environnement à ses limites, on est toujours confronté au besoin de sous-classer, or pour bien sous-classer, on est parfois amené à comprendre quelles méthodes originales sont appelées, dans quel ordre et par qui.
Quid de la doc à ce sujet ? Et si ce n'est pas documenté, quels sont les moyens pour le découvrir ?
Partager