Java pour les nuls, ou Tecka va tout planter Options

C'est le grand jour je me lance, ras le bol de passer pour un gros noob
je me lance dans la programmation mais il faut que je reprenne tout
depuis le début , ma dernière expérience en programmation remonte
à la calculatrice Casio FX850-P. Il me faudrait en premier un environnement
pour faire du Java, vous avez quelque chose de simple et gratos ?
Et si en plus il y a un petit didacticiel c'est encore mieux
Sinon des titres de livres genre "le Java pour les nuls".
Merci

Edit :Je viens de DL Eclipse 3.3 et NetBeans 6.0.1

Ce message a été modifié par Tecka - 8 Mar 2008, 16:20.

Leçon 2 : le MVC/l'architecture N-tiers

Quand on développe un nouveau logiciel, il y a un but et deux logiques s'affrontent pour y parvenir :
- le but est de faire un logiciel qui correspond au cahier des charges initial
- la première logique est de développer le logiciel le plus rapidement possible pour augmenter la rentabilité du produit
- la seconde logique est de penser à la maintenabilité et l'évolutivité du logiciel ("un logiciel qui ne change plus est un logiciel mort", un logiciel dont personne se sert quoi)

Suivant la taille du projet et les circonstances on peut déplacer le curseur entre ces deux logiques à différents endroits.
Pour simplifier pour les petits projets ça sera plus proche de la première logique.
Pour les projets à plusieurs dizaines de jours de développement et dont la durée de vie cible est de 4 ou 5 ans, on favorisera la seconde logique.

Développer en suivant la première logique consiste grosso modo à faire un ou plusieurs gros "scripts" de code (comme du BASIC par exemple). On appelle cela du développement spaghetti.

A contrario, la seconde logique impose un développement plus structuré, pas forcément plus lisible de manière globale en première approche mais plus sûrement modifiable au final. Pour se structurer on peut suivre sa propre intuition mais sans garantie de résultat, ou plus simplement suivre les exemples des personnes intelligentes qui se sont réunies pour réfléchir ensemble et en tirer des modèles fiables.

Dans les années 80, avec l'apparition des applications avec interface graphique un tel modèle est apparu : le MVC (Modèle-Vue-Contrôleur). Je ne vais réexpliquer ce qui est dans l'article de wikipédia, mais en gros on distingue donc trois rôles, trois sortes de travail dans une application et on essaie de répartir correctement ces rôles : un bouton sera créé/réglé dans une partie du code consacrée à la Vue, les calculs métier seront dans le Modèle,...
C'est un modèle efficace pour les applications traditionnelles ou client/serveur (iTunes par exemple, le serveur étant l'iTS dans ce cas). Mais il est assez peu efficace pour les applications Internet/Intranet (qui s'exécutent dans un navigateur web en gros) sauf à prendre des modes de travail un peu plus compliqué (comme GWT).

Vu que ces applications ont quand même plus le vent en poupe que les applications traditionnelles grâce à leurs qualités (déploiement, maintenance,...) et malgré leurs défauts certains (interface limitée par le HTML, plus lent,...), un nouveau modèle s'est dégagé : l'architecture N-tiers (3-tiers dans sa forme la plus utilisée).
Tout d'abord, non ! "tiers" ne signifie par "1/3" mais interlocuteur à l'anglaise, il n'y a donc pas forcément 3 tiers .
Pour résumer le modèle, au lieu d'avoir trois interlocuteurs qui dialoguent librement entre eux comme dans le MVC, on a ici une répartition stricte en couches : 3 couches, chacune ne pouvant échanger des informations qu'avec la couche au-dessus ou en dessous d'elle. Le dialogue est unidirectionnel : couche 1 vers couche 2 ou couche 2 vers couche 1 (en pratique ça se traduit dans le code par :
- couche 1 vers couche 2 : la couche 1 appelle une fonction de la couche 2 en lui passant certains paramètres : la méthode choisie et les paramètres constituent les informations apportées par la couche 1 à la couche 2 dans son dialogue
- couche 2 vers couche 1 : la méthode de couche 2 renvoie une valeur qui est l'information qui est amenée par la couche 2 à la couche 1

Les trois couches sont (de la plus proche de l'utilisateur de l'application à la plus lointaine) : présentation, métier, données persistantes.

Les dialogues dans l'application sont :
- présentation <- métier : récupération des données métiers nécessaires à la construction des pages web de l'application
- client <- présentation : génération des pages web
- client -> présentation : clic sur un lien/validation d'un formulaire/ouverture d'une requête Javascript/...
- présentation -> métier : transfert des informations de l'utilisateur après validation et mise en forme de celles-ci
- métier -> données : après transformation/traitement, passage des informations à sauver
- données -> système de persistance (fichiers, base de données,...) : écriture des données
- données <- système de persistance : chargement des données sauvées précédemment
- métier <- données : après transformation des données brutes en objets métier, passage de ceux-ci

Dans une application Struts (sans framework définie de gestion de la persistance), cela se traduit par exemple par :
- des pages JSP, des classes Action, des classes Form : couche présentation
- des classes Manager, des classes d'objets métier (Business Objects) (par exemple un article dans notre application de gestion des stocks) : couche métier
- des classes DAO, des classes DTO/Value Objects : couche données


La prochaine leçon, on commencera par établir le cahier des charges de notre application de gestion de stocks.

Ce message a été modifié par atarxerxes - 17 May 2008, 11:08.