J'en chie au boulot en ce moment, donc ce poste va dans la categorie boulot (categorie dont tout le monde se fout), mais vraiment, ca me defoule...
Je posterai sur des trucs plus concrets juste apres.
Si vous vous appelez Xav, ne lisez pas la suite (Non Xav, la fonction de la derniere fois ne m'excite pas, elle me degoute plutot - si j'ai bien compris tu as eu la meme reaction- et je voulais juste faire partager mon malheur).

*** mode java ***
Juste quelques points que j'aimerais bien gueuler a la face des mes chefs (enfin ceux qui sont responsables du code source du programme principal, cad les criminels), si possible en les frappant avec un objet contandant de bonne taille (marteau, clavier, imprimante...)


- declarer les variables "protected" :
C'est un moyen d'acceder/modifier facilement des donnees chez une classe du meme package. On deroge un peu a la regle d'or de l'encapsulation totale dans le cas de classes fortement liees (meme package), car on estime qu'il est acceptable de laisser ces classes fortement correlees ET cette forte correlation permet de tabler sur le fait qu'on ne risque pas de rendre l'etat d'un objet incoherent en court-circuitant les chemins etablis.
Ca n'est PAS (EN AUCUN CAS) un moyen de se foutre de l'encapsulation en foutant tout ce qu'on veut dans un package (GUI Swing, Classes gerant l'impression, Classes parsant du XML...), et en appelant tout ca quand on veut directos.
Resultat : ca fait trois jours que je veux JUSTE imprimer un diagramme avec mon programme, ce devrait etre tres simple, MAIS comme dans ce bordel infame, les classes d'impression sont fortement correlees a l'affichage, je me gratte encore la tete pour les decoupler


- les commentaires, c'est bien, mais en japonais c'est con... la doc aussi c'est bien, dommage que personne n'ait eu le courage de faire une javadoc.... Quand on a environ 150 classes pour un systeme de prod, des tests de regression aussi c'est bien (junit pour le riche client, cactus pour le code serveur J2EE)


- la separation des contraintes : si tu as 10 EJBS qui vont acceder a la meme base, ce serait bien d'avoir une classe qui appelle une connection, plutot que d'avoir une fonction dans CHAQUE putain d'EJB pour ca...


- le concept d'EJB :
session : interface avec le client (avec ou sans session) - Note directement via RMI, ou appele par une servlet - , appelle les entity beans et contient le code "entreprise"
entity : represente un objet (=tuple) de la base de donnees, c'est a dire une donnee persistante, resistante a la deconnexion.

ET NON
session : un genre de gros java bean qui attaque la base de donnees direct avec du gros SQL qui tache, et bourre les resultats directement a une servlet
entity : tiens c'est quoi ca ???

Resultat : code acrobatique et tres amateur (confondre EJB et java beans) avec en plus un cote serveur qui melange allegrement code "entreprise" et representation des donnees (essaye de changer tes tables que je me marre...)


- le finally
finally permet, par exemple, de fermer des streams dans le cas d'une fonction presente dans un try et qui declenche une erreur catch. C'est cool de ne pas avoir des streams encore ouverts en cas d'exception non critique
Merde, pensez try-catch-finally plutot que try-catch des que vous risquez de devoir faire du menage pour chaque cas de figure (stream, connection bd, ...)


Je pense qu'a part Pob, personne ne lira ca, mais ca fait du bien :)